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.
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>
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
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
TLS mailing list