+1. If anything, the existing "buggy implementation" alert codes should get folded together. (But I don't think it's worth making that change at this stage either.) E.g. decode_error vs illegal_parameter vs unexpected_message are rather useless distinctions and trying to get them "right" adds complexity. Even with the granularity is it is, TLS's alert codes needlessly expose benign differences in implementation strategy. Adding even finer granularity would make all this worse.
My experience is also that this sort of thing would not actually help much. On Tue, Mar 6, 2018 at 11:05 PM Eric Rescorla <e...@rtfm.com> wrote: > Without taking a position on the security matter: this has been part of > the TLS design for 20+ years, and therefore has had multiple LCs and WG and > IETF consensus, so it would take a pretty strong set of arguments to change > now. I've debugged a lot of TLS interop issues, and as a practical matter, > I don't think this would help that much to justify making a change. > -Ekr > > > On Tue, Mar 6, 2018 at 2:35 PM, Colm MacCárthaigh <c...@allcosts.net> > wrote: > >> >> >> On Fri, Mar 2, 2018 at 8:00 PM, Dale Worley <wor...@ariadne.com> wrote: >> >>> - There are about 28 error codes but nearly 150 places where the text >>> require the connection to be aborted with an error -- and hence, >>> nearly 150 distinct constraints that can be violated. There are 19 >>> alone for "illegal_parameter". I would like to see an "alert >>> extension value" which assigns a distinct "minor" code to each >>> statement in the text that requires an error response (with >>> implementations being allowed to be a bit sloppy in providing the >>> correct minor code). >>> >> >> Your review is incredibly deep, comprehensive and I learned a lot from >> it. I want to pick out just one small piece, but don't mean that to >> diminish how thorough it was! >> >> On the specific suggestion of having more granular error codes, I think >> this is a dangerous direction to take lightly; there's at least one >> instance where granular TLS alert messages have directly led to security >> issues by acting as oracles that aided the attacker. >> >> There's a general conjecture that the more information that is provided >> to attackers, the more easily they can leverage into a compromise. >> Personally I believe that conjecture, and would actually prefer to see >> fewer signals, ideally as few as one big error code. There is a trade-off >> against debugability, but I've only seen a handful of people have the >> skills to debug low level TLS issues and it doesn't seem worth the risk. >> Others disagree, which is valid, but it's at least an area of reasonable >> contention. >> >> -- >> Colm >> > > _______________________________________________ > TLS mailing list > t...@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
