Re: [Tls-reg-review] Early code points for ECH

[Benjamin Kaduk <[e-mail]>]

On Wed, May 27, 2020 at 11:12:44AM -0700, Christopher Wood wrote:
> On Wed, May 27, 2020, at 10:57 AM, Yoav Nir wrote:
> > Yes, I’m OK with early assignment of these values.
> > 
> > However, that is not how things are supposed to work. 
> > 
> > This is the registry: 
> > https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#tls-extensiontype-values-1
> > 
> > Values 57-2569 are marked as Unassigned. That means that at any time 
> > IANA can assign the values 57 and 58. If you deploy some program that 
> > uses these values without IANA assignment, you may have 
> > interoperability problems. That is what the “Reserved for Private Use” 
> > ranges are for. You can pick a number there and test interoperability 
> > among multiple implementations. When the draft gets approved, you 
> > change your implementations to use the assigned values.
> > 
> > In this case the authors chose the numbers by predicting that these 
> > will be the numbers assigned. They were right. I don’t know if they 
> > have running implementations, but likely not any that are deployed at 
> > scale. 
> > 
> > It sometimes happens that people pick a number and use that. This is 
> > especially common in the ciphersuite registry: 
> > https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4
> > 
> > Just search for the phrase "Reserved to avoid conflicts with widely 
> > deployed implementations” and see how many there are. Every one of them 
> > is someone self-allocating a value.
> 
> Thanks -- I understand this. My general question was more along the lines of: is this the best strategy for experimental code points? (QUIC, in contrast, uses varints for code points, thereby removing much of this problem. Implementations just pick a random, long codepoint, and the chance of collision vanishes.)

Perhaps a discussion best had in a broader forum...

-Ben