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