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

[Christopher Wood <[e-mail]>]

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 
> allocating this range.

Great!

Thanks,
Chris