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.
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
Gen-art mailing list