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

[Christopher Wood <[e-mail]>]

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.)

Best,
Chris

> 
> > On 27 May 2020, at 19:58, Christopher Wood <[e-mail]> wrote:
> > 
> > On Wed, May 27, 2020, at 9:32 AM, Yoav Nir wrote:
> >> Any experimental extension should use something from the private use 
> >> range. For extensions that is 65282-65535.
> >> 
> >> The problem is when people want to keep their extension number after 
> >> standardization so they squat on code points.
> > 
> > Can you elaborate on this point? I'm not sure I follow. 
> > 
> > (As for ECH, are you OK with the early assignment?)
> > 
> > Thanks,
> > Chris
> > 
> >> 
> >>> On 27 May 2020, at 1:24, Christopher Wood <[e-mail]> wrote:
> >>> 
> >>> That's a good question. It seems we should have a documented policy or strategy for "extension experiments." (If there is one, I've either not seen it or [more likely] forgotten about it!)
> >>> 
> >>> On Tue, May 26, 2020, at 3:21 PM, Benjamin Kaduk wrote:
> >>>> On Tue, May 26, 2020 at 02:44:25PM -0700, Christopher Wood wrote:
> >>>>> Hi folks,
> >>>>> 
> >>>>> I'd like to kick off the early codepoint allocation process for ECH. We have two extensions that need codepoints. Based on the existing registry, I chose the next two unassigned values and proposed them in this PR:
> >>>> 
> >>>> Not really relevant to the current request, but I wonder whether the
> >>>> experts have opinions on sequential allocation vs. random allocation.
> >>>> 
> >>>> -Ben
> >>>> 
> >>> 
> >>> _______________________________________________
> >>> tls-reg-review mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/tls-reg-review
> >> 
>