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

[Peter Gutmann <[e-mail]>]

Stan Kalisch <[e-mail]> writes:

>On Fri, Apr 6, 2018, at 3:54 PM, Ion Larranaga Azcue wrote:
>>
>> My opinion is that if we are going to have extended error codes, it's
>> better to use numeric ones and not text based errors.
>
>That was my own gut feeling on the least painful way to go, but I'm open to
>the possibility that gut feeling was woefully naive.

To see why this won't work, you just need to think one step further: Try
sitting down and defining the numeric error codes you're proposing.

If it's still not obvious: The reason why we need free-form strings is because
the numeric codes we already have provide insufficient detail.  To provide the
required detail, you'd need to define numeric codes for every error condition
and failed check that every TLS and PKI library (because lots of handshake
failures are due to problems with certs) could wish to communicate.  To take a
PKI example, there's "Certificate chain with length %d has a path constraint
of length %d", which for reasonable values of the two %d leads to, say, around
a hundred error codes just for that one condition.  Then take every single
type of error that would need to be communicated and you're into at least 16-
bit values, or 32- or 64-bit if you take cases like "Packet length of %d
indicated but only %d bytes were sent".

Even if someone came up with the massive codebook of thousands or tens of
thousands of error codes, which TLS author would want to spend hours paging
through them to find the right code for each situation?

Conversely, if you limit the number of error codes to, say, 5,000, how are you
going to convince TLS library authors to check for and report only those
errors?  What happens if new error types are defined?

Peter.