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

From: "Christopher Wood" <[email-masked]>
Date: Tue, 26 May 2020 14:44:25 -0700

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:

   https://github.com/tlswg/draft-ietf-tls-esni/pull/239

Can we please kick off the process? If there's anything I'm missing, please do let me know!

Thanks,
Chris

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 26 May 2020 21:49:55 +0000

In other words, you want

1. encrypted_client_hello(57), with "TLS 1.3" column values being set to
"CH, EE", and "Recommended" column being set to "Yes".
2. outer_extension(58), with the "TLS 1.3" column values being set to
"CH", and "Recommended" column being set to "Yes".

Added to the ExtensionType registry, right?

If so, approved by me.  One down, one of two to go :)

---

From: "Christopher Wood" <[email-masked]>
Date: Tue, 26 May 2020 14:51:19 -0700

Yep -- thanks!

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 26 May 2020 15:21:55 -0700

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

Not really relevant to the current request, but I wonder whether the
experts have opinions on sequential allocation vs. random allocation.

-Ben

---

From: "Christopher Wood" <[email-masked]>
Date: Tue, 26 May 2020 15:24:38 -0700

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

---

From: Yoav Nir <[email-masked]>
Date: Wed, 27 May 2020 19:32:34 +0300

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.

> On 27 May 2020, at 1:24, Christopher Wood <[email-masked]> wrote:
> 
> _______________________________________________
> tls-reg-review mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls-reg-review

---

From: "Christopher Wood" <[email-masked]>
Date: Wed, 27 May 2020 09:58:21 -0700

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

---

From: Yoav Nir <[email-masked]>
Date: Wed, 27 May 2020 20:57:11 +0300

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

> On 27 May 2020, at 19:58, Christopher Wood <[email-masked]> wrote:
>

---

From: "Christopher Wood" <[email-masked]>
Date: Wed, 27 May 2020 11:12:44 -0700

On Wed, May 27, 2020, at 10:57 AM, Yoav Nir wrote:
> 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

---

From: Joseph Salowey <[email-masked]>
Date: Wed, 27 May 2020 18:24:38 -0700

On Wed, May 27, 2020 at 11:13 AM Christopher Wood <[email-masked]>
wrote:

> 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.)
>
>
[Joe] Early assignment is for what you believe the draft is done and there
will be no more technical changes that impact interop.   If the protocol is
still under development and things are likely to change then its better to
use the experimental code points.  The problem with early assignment is
that once the code points are assigned they are allocated.  If the protocol
ends up changing then you will need to ask for new code ponts (which cost
twice as much).  It has happened before that we have burned code points in
this way so it's best to be sure the draft is stable.

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

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 31 May 2020 11:19:09 -0700

> 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 remov…

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

-Ben