Subject: [Tls-reg-review] Temporary allocation of values for TLS extensions

From: Joseph Salowey <[email-masked]>
Date: Fri, 26 Jun 2020 16:00:36 -0700

Attached is a proposal for the temporary allocation of values for TLS
extensions.  This is intended to allow for implementation experiments
during the development of a TLS extension.  This is to address the problem
that the draft may not yet be stabilized enough for a formal allocation.

Let us know what you think.

Cheers,

Joe

---

From: Yoav Nir <[email-masked]>
Date: Sat, 27 Jun 2020 07:06:59 +0300

Two comments about this:
The extensionType registry ([1]) is expressed in decimal rather than hex, so the allocation should be 64251-65279 rather than 0xFAFB-0xFEFF.
We don’t generally set the columns for reserved ranges, like the private-use

Otherwise, I’m not sure if we need a distinction between private-use and experimental use. For interoperability, they’re the same: you can’t count on this value to mean the same thing to your implementation and the peer implementation absent some other handshake mechanism.  That one may be long term while the other should be short-term is largely aspirational.

But extensionType is hardly a scarce resource, so I’m fine with allocating this range.

Yoav

[1] https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#tls-extensiontype-values-1

> On 27 Jun 2020, at 2:00, Joseph Salowey <[email-masked]> wrote:
> 
> Attached is a proposal for the temporary allocation of values for TLS extensions.  This is intended to allow for implementation experiments during the development of a TLS extension.  This is to address the problem that the draft may not yet be stabilized enough for a formal allocation.  
> 
> <draft-wood-tls-experimental-extensions.txt>_______________________________________________
> tls-reg-review mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls-reg-review

---

From: "Christopher Wood" <[email-masked]>
Date: Sun, 28 Jun 2020 06:49:59 -0700

On Fri, Jun 26, 2020, at 9:06 PM, Yoav Nir wrote:
> Two comments about this:
>  1. The extensionType registry ([1]) is expressed in decimal rather 
> than hex, so the allocation should be 64251-65279 rather than 
> 0xFAFB-0xFEFF.

We'll fix this.

>  2. We don’t generally set the columns for reserved ranges, like the 
> private-use
> 
> Otherwise, I’m not sure if we need a distinction between private-use 
> and experimental use. For interoperability, they’re the same: you can’t 
> count on this value to mean the same thing to your implementation and 
> the peer implementation absent some other handshake mechanism. That one 
> may be long term while the other should be short-term is largely 
> aspirational.

They're not the same, though. How does one know if someone else is squatting on a private-use code point? (Answer: you don't!) The purpose here is to allow people to run experiments without having to worry about these sorts of conflicts. QUIC works around this by making types variable length, so the probability of collision after selecting a random codepoint is negligible. Choosing a random code point from the TLS set we have here isn't negligible. So it seems our best bet is to make these private uses transparent.

Would you agree? If not, why not?
 
> But extensionType is hardly a scarce resource, so I’m fine with 

Great!

Thanks,
Chris

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 28 Jun 2020 16:52:24 +0000

I also don't see the need, but I admit that others have different views, and it doesn't cost anything to accommodate them.