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 <[email protected]> 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 <[email protected]> > 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 <[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 >> >> >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
