Re: [TLS] Final nail in the coffin for cleartext SNI/ALPN in TLS 1.3

[Ralf Skyper Kaiser <[e-mail]>]

Hi,

For TLS 1.3 there can be a solution that the SNI is never send in clear.

The downgrade attack to TLS 1.2 is possible and would trigger the SNI to be
send in clear again.
(It requires an active attack).

We need the backward compatibility (from TLS 1.3 to TLS 1.2) for the
foreseeable future. That does not
mean that we should continue with the same flaws in 1.3 that we have in
previous TLS versions.

regards,

ralf



On Thu, Nov 7, 2013 at 8:08 PM, Martin Rex <[e-mail]> wrote:

> Ralf Skyper Kaiser wrote:
> >
> > On Thu, Nov 7, 2013 at 7:46 PM, Yoav Nir <[e-mail]> wrote:
> > >
> > >  IMO, if both sites are either collocated on the same machine, or
> hosted
> > > behind the same SSL accelerator, they already share enough that
> multi-SAN
> > > is not a bad thing.
> > >
> > >  With SNI is it currently stands, the site you are looking for is sent
> in
> > > the clear. If we keep the choose-certificate functionality in 1.3, we
> still
> > > leave it exposed in either the SNI or in the certificate that the
> server
> > > sends. A generic certificate is the only one that hides what the
> client is
> > > browsing.
> > > TLS mailing list
> > >
> >
> > No, SNI can be send encrypted in TLS 1.3 with 'Reduced RT with Privacy'
> as
> > presented by Eric yesterday. Key Exchange is done before SNI is send and
> > auth is done as last. (What's now cleartext would then require
> > detectable-active attack).
>
> I'm sorry, but I firmly believe this will be pure and useless obscurity
> coming at a high cost.
>
> The amount of "activity" for the attack is minuscule (just tear down
> the connection when you see the TLSv1.3 client hello -- the client
> *WILL* reconnect with SNI in the clear.  For the NSA, this is trivial,
> they're actively doing stuff like this on a regular basis (Foxacid).
>
> There are already lots of sites and lots of middle-boxes that cause
> errors like this in a non-malicious fashion, that "detecting" such
> an error is only going to annoy users, but not provide any benefit.
>
> For those negligible situation where there might be any theoretical
> benefit at all, it would be possible to define a seperate TLS extension
> with the properties you're looking for, rather than messing up SNI.
>
> -Martin
>
>