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

From: "Salz, Rich" <[email-masked]>
Date: Sun, 1 Apr 2018 14:37:48 +0000

>    Possibly, if you consider being able to say "Invalid length encoding in
    preferred-ECC-curves extension" in Tswana is mission-critical to debugging a
    TLS handshake failure.
  
I so love your messages, Peter.  Honestly I do.

Perhaps not Tswana, but perhaps China may care to pick a counter-example.

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 05 Apr 2018 22:33:02 -0400

Bill Frantz <[email-masked]> writes:
> We have always avoided the long form error messages in TLS 
> because they can be of great help to attackers as well as 
> debuggers. I think this objection is much weaker if we write the 
> long form error messages into a log that is kept with other 
> server logs.

I'd not considered textual messages.  What struck me is that the draft
has dozens, maybe more than 100, conditions that must be satisfied, and
only a few different error codes.  It strikes me that each particular
rule could be assigned an error number, so an implementation could point
out which of the dozens of rules was violated in a particular handshake.

Dale

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 5 Apr 2018 23:19:55 -0400

> On Apr 1, 2018, at 10:37 AM, Salz, Rich <[email-masked]> wrote:
> 

For debugging messages, I'm with Peter, they'll only be implemented if they're
simple enough to support.  I can't see having to have localization files on the
server for debug messages that might be requested by a client is some other locale
and only when debug is enabled, and the consumer is a developer and not an end-user.

-- 
	Viktor.

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 6 Apr 2018 12:10:35 +0000

The table stakes have increased, and I don't think it is reasonable any more for any IETF protocol to have "just use ASCII" for text messages.  It could be UTF8, or it could be codeset/tagged.  Why two developers in, say, Russia need to speak English to debug their TLS implementations.

---

From: Stan Kalisch <[email-masked]>
Date: Fri, 06 Apr 2018 10:39:49 -0400

Hi,

On Fri, Apr 6, 2018, at 8:10 AM, Salz, Rich wrote:
> The table stakes have increased,

Exactly.

> and I don't think it is reasonable any more for any IETF protocol to
> have "just use ASCII" for text messages.  It could be UTF8, or it
> could be codeset/tagged.  Why two developers in, say, Russia need to
> speak English to debug their TLS implementations.
Viktor rightly points out that in this situation the developer is the
consumer.  As the Internet exponentially expands—often in ways we're not
always able to posit ahead of time—the base of developers exponentially
expands.  The IETF shouldn't be sanguine about the possibility that at
some point the number of those developers who do not speak English will
reach a critical mass that is able to start eschewing protocols that it
finds too mired in US-ASCII.
I would ask anybody who would say it could never happen how sure they
are of that assertion.

Thanks,
Stan

---

From: Ion Larranaga Azcue <[email-masked]>
Date: Fri, 6 Apr 2018 19:54:36 +0000

Hi,

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. Imagine a chinese client trying to troubleshoot a connection to a server using a TLS stack that reports its errors in russian. That would be crazy!

I'm not saying that forcing English is better. There are many people out there who have problems with english as well, and I'm sure that they would rather look a numeric code in a table with localized error messages than having to use google translate.

That being said...

If in the end a decission is made to have text based error messages, I think that the messages should be (at least) UTF-8. If a developer wants to generate an error message including information from the certificate (I can't imagine a valid scenario but... why not?), there are many places where UTF-8 is allowed. Additionally, a server name can also contain non-ASCII characters and so on...

________________________________
De: TLS <[email-masked]> en nombre de Stan Kalisch <[email-masked]>
Enviado: viernes, 6 de abril de 2018 16:39
Para: [email-masked]
Asunto: Re: [TLS] Genart last call review of draft-ietf-tls-tls13-24

Hi,

Exactly.

and I don't think it is reasonable any more for any IETF protocol to have "just use ASCII" for text messages.  It could be UTF8, or it could be codeset/tagged.  Why two developers in, say, Russia need to speak English to debug their TLS implementations.

Viktor rightly points out that in this situation the developer is the consumer.  As the Internet exponentially expands-often in ways we're not always able to posit ahead of time-the base of developers exponentially expands.  The IETF shouldn't be sanguine about the possibility that at some point the number of those developers who do not speak English will reach a critical mass that is able to start eschewing protocols that it finds too mired in US-ASCII.

I would ask anybody who would say it could never happen how sure they are of that assertion.

Thanks,
Stan

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 6 Apr 2018 23:11:28 +0000

On Fri, Apr 06, 2018 at 12:10:35PM +0000, Salz, Rich wrote:

> The table stakes have increased, and I don't think it is reasonable any
> more for any IETF protocol to have "just use ASCII" for text messages.
> It could be UTF8, or it could be codeset/tagged.  Why two developers in,
> say, Russia need to speak English to debug their TLS implementations.

Because the server has no idea what locale the client is in.
Localization is not an option.  The only option (which is essentially
"use-ascii") is to use UTF-8, and then the error messages are in
whatever language the developer of the server used.  So the Russian
developer will be seeing Chinese debug messages from the server.
That's not progress.

If you want localization, the messages need to be numeric codes,
with localized string tables on each client.  But then older clients
might not understand some new server messages (perhaps OK if the
message list is sufficiently stable given a client protocol version
and set of client supported extensions).

-- 
	Viktor.

---

From: Stan Kalisch <[email-masked]>
Date: Fri, 06 Apr 2018 19:26:31 -0400

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.

Stan

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 6 Apr 2018 16:39:54 -0700

On Fri, Apr 6, 2018 at 4:11 PM, Viktor Dukhovni <[email-masked]>
wrote:

> Localization is not an option.

That would depend on how you designed the feature. Because the client would
have
to opt-in in any case, it could provide its locale in that opt-in message.

I'm not saying that this (or even the feature at all) is necessarily a good
idea, but
it's not like it's impossible.

-Ekr

The only option (which is essentially
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 7 Apr 2018 00:49:32 -0400

> On Apr 6, 2018, at 7:39 PM, Eric Rescorla <[email-masked]> wrote:
> 
> That would depend on how you designed the feature. Because the client would have
> I'm not saying that this (or even the feature at all) is necessarily a good idea, but

Yes, it is not impossible, but it is much too brittle.  There's little reason (in general)
to expect the server to have support for the client's locale, let alone have locale-specific
translation tables for TLS errors.  Numeric codes are much better if the error reasons are
easily to classify in advance. Otherwise, numeric codes + UTF8 text in English.

This works with enhanced status codes in SMTP, which some MUAs (Outlook) render in local
languages based on the status code, but the remote postmaster will want the original text,
so that's often more useful for debugging when there's a problem (and not just a wrong
email address).

-- 
	Viktor.

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 7 Apr 2018 14:25:29 +0000

Just make the text message UTF8.  Is that so hard, so distasteful?  This gets a very common use-case and is useful for debugging.

I used to say "just teach 'em all English," but that was 25 years ago and I was not serious.

---

From: Peter Gutmann <[email-masked]>
Date: Sun, 8 Apr 2018 00:37:56 +0000

I can't believe the amount of pointless bikeshedding that's already been done
over something that's going to be a rarely-if-ever used mechanism for one set
of hardcore technical developers to communicate to another set of hardcore
technical developers.  This isn't a design for a multilingual IM system with
emojis and animated GIFs, it's a rarely-used debugging/diagnostic facility,
and yet we're arguing over whether a developer who can read a lengthy
technical document specified entirely in US-ASCII (TLS RFC) and implement it
in C or Java (US-ASCII, English keywords) will be unable to communicate an
error message in anything but Cantonese (or Mandarin, or Qiang, or Kam–Sui, or
Kipchak, or whatever was meant by "Chinese").

Even for the few steps in the process where there's i18n available like the
gcc compile stage, the Chinese-speaking devs I know use the English version
because they don't want an attempted guess in another language at what the
error is, they want the actual error message from the compiler authors (many
gcc error messages are barely comprehensible in English, let alone in an
Uighur translation.  Or maybe there are in Uighur, which is why I have trouble
figuring out what they're saying).

In any case it's a rarely-used, optional, by-special-request debugging
facility for technical developers, make it UTF-8 and the devs can decide what
they put in there.

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Sun, 8 Apr 2018 00:40:31 +0000

Stan Kalisch <[email-masked]> writes:

>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.

---

From: Ion Larranaga Azcue <[email-masked]>
Date: Mon, 9 Apr 2018 09:28:21 +0000

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:[email-masked]] 
Enviado el: domingo, 8 de abril de 2018 2:41
Para: Ion Larranaga Azcue <[email-masked]>
CC: [email-masked]
Asunto: Re: [TLS] Genart last call review of draft-ietf-tls-tls13-24

Stan Kalisch <[email-masked]> writes:

>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.

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 9 Apr 2018 09:50:11 +0000

Ion Larranaga Azcue <[email-masked]> 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.  [email-masked] 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.

---

From: Ion Larranaga Azcue <[email-masked]>
Date: Mon, 9 Apr 2018 11:20:46 +0000

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:[email-masked]] 
Enviado el: lunes, 9 de abril de 2018 11:50
Para: Ion Larranaga Azcue <[email-masked]>
CC: [email-masked]
Asunto: Re: [TLS] Genart last call review of draft-ietf-tls-tls13-24

>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.  [email-masked] 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.

---

From: Stan Kalisch <[email-masked]>
Date: Mon, 9 Apr 2018 19:34:17 -0400

> On Apr 7, 2018, at 8:37 PM, Peter Gutmann <[email-masked]> wrote:
> 
> I can't believe the amount of pointless bikeshedding that's already been done over something that's going to be a rarely-if-ever used mechanism for one set
> of hardcore technical developers to communicate to another set of hardcore technical developers.

Not to be too Steve Jobs about it, but I was simply trying to have a little imagination and question assumptions (including my own) about how the size of the developer base could grow, and what that could mean.  So if being thoughtful to the point where one has the occasional slight digression is bikeshedding, that's fine with me.

> This isn't a design for a multilingual IM system with emojis and animated GIFs,

Thank you for clearing that up.

> it's a rarely-used debugging/diagnostic facility,
> technical document specified entirely in US-ASCII (TLS RFC) and implement it in C or Java (US-ASCII, English keywords) will be unable to communicate an error message in anything but Cantonese (or Mandarin, or Qiang, or Kam–Sui, or

Actually, no, we're not arguing over that.

> Even for the few steps in the process where there's i18n available like the gcc compile stage, the Chinese-speaking devs I know use the English version because they don't want an attempted guess in another language at what the
> error is,

And because they also know English.

Thanks,
Stan