Subject: [quicwg/base-drafts] encoding of CONNECTION_CLOSE reason phrases (#1990)

From: Marten Seemann <[email-masked]>
Date: Sat, 10 Nov 2018 22:57:17 -0800

There recently was a Human Rights review of the QUIC protocol, which identified a potential issue with the encoding of CONNECTION_CLOSE frames: https://tools.ietf.org/id/draft-martini-hrpc-quichr-00.html#internationalization.

I don't know how many people read this document, so I'm opening this issue. Not sure if we actually need to do something about it, but we should at least consider their recommendation.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1990

---

From: MikkelFJ <[email-masked]>
Date: Sun, 11 Nov 2018 00:38:56 -0800

I think MUST UTF-8 is fine, this also solves endian issues.

The language SHOULD br english when interoperability is required, but MAY be any language that all endpoints are willing to accept within a closed deployment.

Specifying language codes isn’t really helpful as you can’t really make use of the text if you don’t recognize it immediately, and it just complicates matters.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1990#issuecomment-437652706

---

From: Martin Thomson <[email-masked]>
Date: Sun, 11 Nov 2018 15:47:33 -0800

The problem here is that tagging isn't that useful unless you also couple it with negotiation.  We can annotate the string with a language tag, but that doesn't make the text more comprehensible if the chosen language isn't understood.  If the endpoint is able to generate translated strings, then it doesn't know which one to use.  It's possible that we could signal the preferred language of endpoints in transport parameters, but that leaves clients exposing their language preferences in the clear.  

Then we need to consider that the language preferences of the endpoint might not even be relevant.  This information is largely only useful during debugging, so it is the language preference of the stack developer that is likely to matter.  That said, if the messages were passed to the stack developer, that is likely to represent a risk to the privacy of the endpoints or those using those endpoints.  And there is a risk of misinterpretation if the language preference of the person using the endpoint differs from that of the stack developer.

In other words, this isn't a trivial problem.  We could just tag the message and leave it to online translation tools and the like to sort things out, I guess.  But @mikkelfj's conclusion is the one we took in HTTP/2, though we chose to say nothing in that case.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1990#issuecomment-437716951

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 11 Nov 2018 22:42:34 -0800

What @martinthomson says.

The field is purely for debugging, and we do not need to internationalize it.

I am fine with changing the definition from "human-readable explanation that SHOULD be UTF-8" to "a series of octets that can be anything" if doing so removes the misconception that the information contained here requires I18N.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1990#issuecomment-437773390

---

From: Marten Seemann <[email-masked]>
Date: Sun, 11 Nov 2018 22:48:38 -0800

I agree that this is purely for debugging, and should probably never be displayed to the user, so I18n shouldn't be an issue.

Is there any reason not to require this to be UTF-8 though? I think it would help debugging interoperability testing (and error logging) if you can rely on the charset.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1990#issuecomment-437774510

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 11 Nov 2018 23:11:06 -0800

> Is there any reason not to require this to be UTF-8 though? I think it would help debugging interoperability testing (and error logging) if you can rely on the charset.

If we say "MUST be UTF-8", then the natural outcome would be that people would expect QUIC stacks to validate if the reason phase contains a valid UTF-8 string. I do not think we should have such a requirement.

Current text saying "SHOULD be UTF-8" is fine in this respect because QUIC stacks can simply emit the binary octets that it has received to the application.

Note that most (if not all) of HTTP logging does not deal with charsets; for example a URL can contain any charset, and they are logged as bytes.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1990#issuecomment-437779182

---

From: Martin Thomson <[email-masked]>
Date: Mon, 12 Nov 2018 01:34:26 -0800

You can't realistically generate an error if CONNECTION_CLOSE is bad, so I don't have a problem saying that it contains a UTF-8 string.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1990#issuecomment-437814361

---

From: MikkelFJ <[email-masked]>
Date: Mon, 12 Nov 2018 01:37:57 -0800

If it's UTF-8 it is much simpler to dump in error logs, even if you don't bother validate it. Some logs tend to use JSON which is practically always UTF-8. If you need binary, just base64 encode it.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1990#issuecomment-437815343

---

From: MikkelFJ <[email-masked]>
Date: Mon, 12 Nov 2018 01:39:45 -0800

A binary format is a buffer overrun attack waiting to happen.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1990#issuecomment-437815817

---

From: janaiyengar <[email-masked]>
Date: Mon, 12 Nov 2018 02:57:55 -0800

I am inclined to leave the text as it is. The primary motivation for i18n
is for user-visible text, and this text is not really it. For devs, I can't
imagine that language tags will help when the entire protocol is in
English. I'm fine with a SHOULD for UTF-8, and leave the implications of
non-UTF-8 encodings to implementations.

On Mon, Nov 12, 2018 at 4:39 PM MikkelFJ <[email-masked]> wrote:

> —
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/issues/1990#issuecomment-437815817>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AKjg1EpokMDO1b6EefhYi9TNocX6ZNKvks5uuUHhgaJpZM4YYWmQ>
> .
>

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1990#issuecomment-437838686

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 12 Nov 2018 04:10:38 -0800

@mikkelfj 
> If it's UTF-8 it is much simpler to dump in error logs, even if you don't bother validate it. Some logs tend to use JSON which is practically always UTF-8.

Don't do that. Because this is how you create a DoS attack vector on the server side.

If the reason phase contained an invalid UTF-8 sequence, creating a JSON that contains that reason phase makes the entire JSON invalid. Because many JSON decoders refuse to return anything when the input contains an invalid UTF-8 sequence, you essentially destroy all the information that were stored in JSON.

For example, consider you have an automated system that collects the reason phases for all the connections sent by the peer. Having just one invalid reason phase stops the entire system.

To summarize, calling it "MUST UTF-8" does not make things simpler.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1990#issuecomment-437856770

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 12 Nov 2018 04:13:18 -0800

@janaiyengar 
> For devs, I can't imagine that language tags will help when the entire protocol is in English. I'm fine with a SHOULD for UTF-8, and leave the implications of non-UTF-8 encodings to implementations.

+1.

Most HTTP logs use ASCII as their output, escaping out-of-range characters using some kind of notation (e.g., `\xNN`). Assuming that the reason phrase be in English in practice, we can log the contents of the reason phase the same way as we log the HTTP headers.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1990#issuecomment-437857387

---

From: MikkelFJ <[email-masked]>
Date: Mon, 12 Nov 2018 04:33:17 -0800

Docker tends to log to JSON. While that isn't very efficient, that is what happens. I'm not sure what kind of validation happens behind the scenes, but I'd assume it would escape anything that isn't valid UTF-8, or at least anything that contains a null character. That said, Docker is perfectly capable of DOS'ing itself without outside help.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1990#issuecomment-437862809

---

From: Lars Eggert <[email-masked]>
Date: Mon, 12 Nov 2018 10:05:28 -0800

For debugging purposes, you could just always include a unidirectional STREAM frame with any reason text...

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1990#issuecomment-437976009

---

From: Lars Eggert <[email-masked]>
Date: Mon, 12 Nov 2018 10:03:40 -0800

So at the moment, I think quant is the only stack that actually put something into that field. Given that other stacks aren't even doing it when we should be heavily debugging, maybe we just remove the field entirely?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1990#issuecomment-437975470

---

From: MikkelFJ <[email-masked]>
Date: Mon, 12 Nov 2018 10:37:54 -0800

I think text is probably useful for all the errors that have no precise error code as implementations become more refined and error check peer input more thoroughly. The alternative could be a request for a lot more error messages. E.g. what is protocol violation?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1990#issuecomment-437985868

---

From: Dmitri Tikhonov <[email-masked]>
Date: Mon, 12 Nov 2018 19:00:35 +0000 (UTC)

> I think quant is the only stack that actually puts something into that field.

LiteSpeed QUIC puts useful information into the reason field of the CONNECTION_CLOSE frame as well.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1990#issuecomment-437992670

---

From: ianswett <[email-masked]>
Date: Mon, 12 Nov 2018 11:03:09 -0800

gQUIC is definitely using the reason field and intends to continue using it.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1990#issuecomment-437993419

---

From: martinduke <[email-masked]>
Date: Mon, 12 Nov 2018 15:46:07 -0800

@larseggert f5 sometimes puts something in there. In TCP-land we have weird hacks to include RST reasons in our packet traces, and believe this field is useful in the real world.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1990#issuecomment-438073320

---

From: Mike Bishop <[email-masked]>
Date: Tue, 13 Nov 2018 12:10:26 -0800

@janaiyengar, the protocol isn't in English, it's in binary.  The RFC is in English, but that doesn't mean there won't be translations later.  (E.g. [RFC7540 in Chinese](https://github.com/abbshr/rfc7540-translation-zh_cn))

This is ultimately useful for the developer of the implementation emitting it, so they know what language to expect there.  The key requirement for everyone else is something easy to log and relay back to that developer, and I think UTF-8 is our best option there.  I'd support MUST UTF-8.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1990#issuecomment-438418928

---

From: janaiyengar <[email-masked]>
Date: Wed, 14 Nov 2018 20:00:54 -0800

(I do think the protocol is in English and Binary. The protocol is not only
what's on the wire, it's also what to do with the bits, and that's the RFC.
I'll concede that there can be translations though.)

On Wed, Nov 14, 2018 at 1:40 AM Mike Bishop <[email-masked]>
wrote:

> @janaiyengar <https://github.com/janaiyengar>, the protocol isn't in
> English, it's in binary. The RFC is in English, but that doesn't mean there
> won't be translations later. (E.g. RFC7540 in Chinese
> <https://github.com/abbshr/rfc7540-translation-zh_cn>)
>
> This is ultimately useful for the developer of the implementation emitting
> it, so they know what language to expect there. The key requirement for
> everyone else is something easy to log and relay back to that developer,
> and I think UTF-8 is our best option there. I'd support MUST UTF-8.
>
> —
> You are receiving this because you were mentioned.
> <https://github.com/quicwg/base-drafts/issues/1990#issuecomment-438418928>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AKjg1KgJ8senerh3wILBYg-bsM2BMbBHks5uuycygaJpZM4YYWmQ>
> .
>

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1990#issuecomment-438909280