We might also want to mark 40 similarly given the ExtendedRandom collision that caused issues with key_share.
On Thu, May 31, 2018 at 11:10 AM Benjamin Kaduk <bkaduk= 40akamai....@dmarc.ietf.org> wrote: > 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 > -- Steven Valdez | Chrome Networking | sval...@google.com | 210-692-4742
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
