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 <[email protected]> wrote: > > > On Fri, Mar 2, 2018 at 8:00 PM, Dale Worley <[email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/tls
