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
TLS mailing list