Re: [TLS] Protocol Action: 'IANA Registry Updates for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)' to Proposed Standard (draft-ietf-tls-iana-registry-updates-05.txt)

Just picking a random high number for QUIC seems reasonable for this stage.
None of this still will escape outside of draft QUIC versions (which,
themselves, will be short-lived) and a collision at high numbers isn't
likely anyway. Our problems with 26 and 40 are because we like to make
"official" allocations consecutively, and then "unofficial" allocations
missed the obvious corollary: do not mimic this.

On Thu, May 31, 2018 at 10:51 AM Eric Rescorla <ekr@rtfm.com> wrote:

> Based on this, I propose that IANA allocates a new !26 Early Data code
> point for compressed certificates (that's mechanical).
>
> As noted earlier, it's premature for TLS-LTS to request a code point
> because the enabling document has not yet been published, so we can defer
> the question of its use of 26 for a bit.
>
> The QUIC TLS extension should also change to a new code point, but I'm not
> sure it meets the criteria for an early code point assignment. MT proposed
> just squatting on a random code point. Having a really unique code point is
> less important here because this extension will only appear inside of QUIC
> and not on ordinarily TLS connections, though of course it must have a
> unique code point from other extensions used with QUIC. So it's not
> entirely clear how best to handle this,
>
> -Ekr
>
>
> On Thu, May 31, 2018 at 7:42 AM, David Benjamin <davidben@chromium.org>
> wrote:
>
>> I probed a bunch of servers yesterday and found evidence of yet another
>> collision at 26! It's possible these are TLS-LTS implementations, but a lot
>> of them additionally only support RSA decryption ciphers, which makes this
>> seem unlikely. These servers do not appear to do anything with the
>> extension, as far as I could tell, including even echoing it back, but
>> they  send decode_error if the extension includes a non-empty body. (It's
>> possible their TLS implementation supports TLS-LTS, unconditionally parses
>> the extension, but does not actually enable it by default.)
>>
>> I didn't repeat the probe with 27, but playing with a couple of the
>> servers showed they tolerate other numbers fine, including 27. It's just
>> that they appear to have squatted on 26 for something.
>>
>> It's frustrating that allocating code points is complicated, but given
>> the other deployment problems TLS has seen lately, were this the worst of
>> our problems, I would be quite happy.
>>
>> On Thu, May 31, 2018 at 1:56 AM Joseph Salowey <joe@salowey.net> wrote:
>>
>>> I agree we should use a different number than 26 for certificate
>>> compression.  I don't see a problem with assigning 27 and reserving 26 for
>>> now.
>>>
>>> On Wed, May 30, 2018 at 8:13 PM, Adam Langley <agl@imperialviolet.org>
>>> wrote:
>>>
>>>> On Tue, May 29, 2018 at 6:16 PM Jeffrey Walton <noloader@gmail.com>
>>>> wrote:
>>>> > I also delivered an OpenSSL-based TLS-LTS prototype to a Hoteliers
>>>> > working group for their smart locks last year. I have no idea how much
>>>> > of the code they are going to reuse (if any at all).
>>>>
>>>> Chrome / Google is blocked on code-point assignment for deploying
>>>> certificate compression. It appears that 26 is not a good pick and we
>>>> thus wait in anticipation for a replacement.
>>>>
>>>> (The extensions space is effectively infinite: if we get close to
>>>> running out, we can assign an "extended extensions" code point, which
>>>> would contain a nested extensions block with 32-bit numbers instead.
>>>> Therefore effort and delays resulting from treating it as a scarce
>>>> resource are saddening. Speaking in a personal capacity, it looks like
>>>> 26 is TLS-LTS, maybe 27 for compression? Or else we could assign them
>>>> randomly to avoid issues with concurrent applications and I offer
>>>> 0xbb31 as a high-quality, random number. Since we had a triple
>>>> collision in this case, random-assignment's virtues are currently
>>>> particularly clear.)
>>>>
>>>> --
>>>> Adam Langley agl@imperialviolet.org https://www.imperialviolet.org
>>>>
>>>
>>> _______________________________________________
>>> TLS mailing list
>>> TLS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tls
>>>
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>>
>