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

On Thu, Nov 7, 2013 at 1:39 PM, Ralf Skyper Kaiser <skyper@thc.org> wrote:
> 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).
Why wasn't this fixed years ago? The client should indicate the
highest offered version when falling back, and the server should
signal if there is a problem. This was an issue with SSL 3.0 and TLS
1.0. It's still an issue today because SSL 3.0 is still out there.
>
> 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 <mrex@sap.com> wrote:
>>
>> Ralf Skyper Kaiser wrote:
>> >
>> > On Thu, Nov 7, 2013 at 7:46 PM, Yoav Nir <ynir@checkpoint.com> 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
>>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>


-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin