Re: [TLS] Protocol Action: 'IANA Registry Updates for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)' to Proposed Standard (draft-ietf-tls-iana-registry-updates-05.txt)

[Benjamin Kaduk <[e-mail]>]

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

> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls