I think you don't really get my position in this issue... No, I'm not going to 
start a list of numeric codes because I don't believe in this functionality. 
Not even numeric extended alert codes have any appeal to me, it's just the 
least offending idea.

In my opinion, someone wants this functionality because he doesn't want to ask 
the server administrators to analyze or even send the debug logs in the peer 
side, which already have the information he needs. He is trying to substitute a 
person-to-person interaction he doesn't want to perform for a 
computer-to-computer interaction he sees as more convenient. Maybe without 
realizing he still needs to ask peer administrators to enable this debug 
functionality on a (most likely) production server.

So, I'm totally against this whole idea but if everybody else supports it, I'm 
going to try to do damage control and suggest limiting the amount of 
information that can (will) be leaked.

-----Mensaje original-----
De: Peter Gutmann [mailto:pgut...@cs.auckland.ac.nz] 
Enviado el: lunes, 9 de abril de 2018 11:50
Para: Ion Larranaga Azcue <ila...@s21sec.com>
CC: tls@ietf.org
Asunto: Re: [TLS] Genart last call review of draft-ietf-tls-tls13-24

Ion Larranaga Azcue <ila...@s21sec.com> 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 

>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.  tls-error-bikeshedd...@ietf.org 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.


TLS mailing list

Reply via email to