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)

[Eric Rescorla <[e-mail]>]

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 <[e-mail]>
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 <[e-mail]> 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 <[e-mail]>
>> wrote:
>>
>>> On Tue, May 29, 2018 at 6:16 PM Jeffrey Walton <[e-mail]>
>>> 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 [e-mail] https://www.imperialviolet.org
>>>
>>
>> _______________________________________________
>> TLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>
>