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 TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
