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
