Re: [Gen-art] Genart last call review of draft-ietf-tls-tls13-24

[Eric Rescorla <[e-mail]>]

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 <[e-mail]> wrote:

>
>
> On Fri, Mar 2, 2018 at 8:00 PM, Dale Worley <[e-mail]> 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
>