Re: Codepoint allocation for TLS extension

[David Schinazi <[e-mail]>]

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 <[e-mail]> 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
>
>