Subject: Codepoint allocation for TLS extension

From: "Martin Thomson" <[email-masked]>
Date: Tue, 08 Dec 2020 20:40:44 +1100

Hi Everyone,

I'm fairly sure that most people are deploying QUIC with the quic_transport_parameters TLS extension using the 0xffa5 codepoint in the current draft.

Unfortunately, this can't stand.  That's a private use codepoint in TLS.  The final version of QUIC will need a permanent allocation.  This should be a problem in terms of collisions in the short term as QUIC can't conflict with TCP use of TLS, but TLS expressly permits use of this codepoint for private use, so we can't guarantee that TLS stacks won't try to use this codepoint.

I know that this is disruptive, and apologize for this not being clear earlier.  It was originally, but a lot of time has passed since then and I'm sure that many, like me, have forgotten this detail.  

Hopefully this can be rectified without much fuss.  IANA has already requested expert review for the allocation (I believe), so it might just be a matter of getting the final allocation.

Chairs, and AD, 
Following the procedures in Section 3.1 of RFC 7120, this is my request for early allocation of a codepoint, in case that is necessary.  I've provided more context to those involved privately.

I hope to have the final codepoints (version numbers, salt, retry keys, transport parameter extension) in -33, which will go to the IESG for approval in the next few weeks.

--Martin

---

From: David Schinazi <[email-masked]>
Date: Tue, 8 Dec 2020 08:31:26 -0800

Ah that is unfortunate, but I agree that we should fix it.
>From Google's perspective, I think we'll keep the old
TLS codepoint in h3-29, and switch to the new one when
we ship the QUIC RFC version.

David

On Tue, Dec 8, 2020 at 1:41 AM Martin Thomson <[email-masked]> wrote:

> Hi Everyone,
>
> I'm fairly sure that most people are deploying QUIC with the
> quic_transport_parameters TLS extension using the 0xffa5 codepoint in the
> current draft.
>
> Unfortunately, this can't stand.  That's a private use codepoint in TLS.
> The final version of QUIC will need a permanent allocation.  This should be
> a problem in terms of collisions in the short term as QUIC can't conflict
> with TCP use of TLS, but TLS expressly permits use of this codepoint for
> private use, so we can't guarantee that TLS stacks won't try to use this
> codepoint.
>
> I know that this is disruptive, and apologize for this not being clear
> earlier.  It was originally, but a lot of time has passed since then and
> I'm sure that many, like me, have forgotten this detail.
>
> Hopefully this can be rectified without much fuss.  IANA has already
> requested expert review for the allocation (I believe), so it might just be
> a matter of getting the final allocation.
>
> Chairs, and AD,
> Following the procedures in Section 3.1 of RFC 7120, this is my request
> for early allocation of a codepoint, in case that is necessary.  I've
> provided more context to those involved privately.
>
> I hope to have the final codepoints (version numbers, salt, retry keys,
> transport parameter extension) in -33, which will go to the IESG for
> approval in the next few weeks.
>
> --Martin
>
>

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 09 Dec 2020 08:35:15 +1100

> we ship the QUIC RFC version.

Yep. That is the only option that will both match the spec and interoperate :)

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 8 Dec 2020 16:02:48 -0800

+1 to changing it for v1. Thanks for catching this, Martin.

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 11 Dec 2020 10:17:54 +1100

Just a follow-up.  IANA has provided a number (after one false start).  I've tested it, but I will ask that people test the changes in the upcoming -33 as soon as they are able.  I don't want there to be any mistakes.

*** Please don't deploy version 1 anywhere just yet. ***

Draft-29 (or later) is still perfectly good for interoperability testing and we'd like reserve the option to redefine what version 1 is for just a while longer.  If you deploy and we are forced to change something, you will spoil it for everyone.

Thanks to IANA, the TLS chairs and experts, our chairs, and Magnus for being responsive to this request.

On Tue, Dec 8, 2020, at 20:40, Martin Thomson wrote:
> quic_transport_parameters TLS extension using the 0xffa5 codepoint in 
> the current draft.
> 
> Unfortunately, this can't stand.  That's a private use codepoint in 
> TLS.  The final version of QUIC will need a permanent allocation.  This 
> should be a problem in terms of collisions in the short term as QUIC 
> can't conflict with TCP use of TLS, but TLS expressly permits use of 
> this codepoint for private use, so we can't guarantee that TLS stacks 
> won't try to use this codepoint.
> 
> earlier.  It was originally, but a lot of time has passed since then 
> and I'm sure that many, like me, have forgotten this detail.  
> 
> requested expert review for the allocation (I believe), so it might 
> just be a matter of getting the final allocation.
> 
> Chairs, and AD,