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

[Peter Gutmann <[e-mail]>]

Ion Larranaga Azcue <[e-mail]> writes:

>I don't think it's necessary going to that degree of detail. For your
>specific first example, alert the alert "bad_certificate" is enough

We already have error codes at about that level.  They're not enough to debug
any problems (I mean, "bad certificate" is only marginally better than the
canonical Ken Thompson Unix error message in which a giant "?" lights up in
front of you, "the experienced TLS developer will usually know what's wrong"),
thus the need for free-form text messages that tell you what the actual
problem is.

>The problem I see with it is that it's hard for applications to automatically
>parse it,

Applications don't need to parse it, it's an optional, opt-in
debugging/diagnostic facility to help developers sort out why a handshake is
failing, not something that an application is meant to process.

>I would first start trying to define an extended error reporting protocol
>using only numeric codes

Please, go ahead and do so.  For that we'll probably need to start a new list
to allow everyone to debate at length which error codes are needed and what
they should represent.  [e-mail] seems to be a good
candidate name.

Either that or say it's a UTF-8 string with free-form text, and we'll assume
developers can somehow manage to figure the rest out themselves, as they have
for pretty much every other situation in which free-form text error messages
are used.

Peter.