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, or at the most a "certificate_chain_length_error". Your second example is, for me, more real, because it can be an extended error for a "decode_error" alert. As "decode_error" is too broad, we could have a "length_mismatch" extended error. But not give the specific values, because once the user knows that there is an error with the length of a packet, it can revise length fields in that specific packet in order to identify the error. An additional intermediate option is allowing specific parameters for each extended error, for instance in this example it could be the location within the packet of the offending field.
Summarizing, including a text error message is going from black to white without passing through the greys. The problem I see with it is that it's hard for applications to automatically parse it, should it become necessary. I would first start trying to define an extended error reporting protocol using only numeric codes, and after the first few attempts, if we see that the list is not manageable, we could start exploring other options. My preferences are (in descending order of preference): - leave it as it is now, no extended error codes - numeric extended error codes - numeric extended error codes with specific sub-parameters for each extended error code (e.g. location within the packet of offending length field in a "length_mismatch" extended error code) - numeric extended error codes with an arbitrary list of opaque parameters each, to be filled by developer (implementations can't rely on the content but can show them, on screen, so if you want it can be a text message) - a single opaque extended error code. It can be numeric, UTF8 string or what the developer wants, but in my opinion this should be the last resort. I have never liked "let me put whatever I want" solutions -----Mensaje original----- De: Peter Gutmann [mailto:pgut...@cs.auckland.ac.nz] Enviado el: domingo, 8 de abril de 2018 2:41 Para: Ion Larranaga Azcue <ila...@s21sec.com> CC: tls@ietf.org Asunto: Re: [TLS] Genart last call review of draft-ietf-tls-tls13-24 Stan Kalisch <s...@glyphein.mailforce.net> 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. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
