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)

[Steven Valdez <[e-mail]>]

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


-- 

Steven Valdez |  Chrome Networking |  [e-mail] |  210-692-4742