I think there's also some room to just mark 26 as "Reserved - unauthorized use has rendered this value unsuitable for official allocation".
-Ben On Thu, May 31, 2018 at 07:50:46AM -0700, Eric Rescorla 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 <david...@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 <j...@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 <a...@imperialviolet.org> > >> wrote: > >> > >>> On Tue, May 29, 2018 at 6:16 PM Jeffrey Walton <noloa...@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 a...@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 > > > > > _______________________________________________ > 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
