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 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. 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. Peter. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
