Re: Codepoint allocation for TLS extension

[Martin Thomson <[e-mail]>]

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