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

[[e-mail] (Martin Rex)]

Daniel Kahn Gillmor wrote:
> Martin Rex wrote:
>> 
>> But you are aware that there is no such thing as a
>> "confidential DNS lookup" (confidential towards whom anyways),
>> so that in general, what your browser is connecting will be
>> directly preceded by a cleartext DNS lookup with that very name...
> 
> Sure, but that is a bug in DNS, not a bug in TLS, and there are 
> proposals (however farfetched) to work around that, like DNSCurve [0]. 
> But fixing DNS leakage is out-of-scope for this working group.

No need to develop and deploy anthing.
Just switch on IPsec (which allegedly is, according to the IPv6 fanciers,
already deployed everywhere).  This could adequately protect not only
DNS lookups, but also the entire cleartext phase of TLSv1.0/1/2 handshakes.
 
>
> Fixing TLS is in-scope, though, and TLS shouldn't leak information just 
> because other related protocols also leak information.

Don't fix it if it ain't broken.
SNI was specifically DESIGNED to convey the server name in the clear.

Security only works in a meaningful fashion if you can ensure "hygiene",
otherwise it will be expensive obscurity and result in casualties.


> 
> Putting SNI info in an encrypted handshake would make that information 
> unavailable to passive attackers.

This is a dangerious illusion.  As long as SNI will travel in the clear in
protocol versions up to TLSv1.2, it *WILL* leak.  Maybe not from your
client, but someone elses older client going to the same service.

TLSv1.2 (rfc5246) was published in 2008, and its adoption rate is
about as bad as that of IPv6.  The more changes there are proposed
for TLSv1.3, the worse it will fail in the installed base.
TLSv1.2 already is a proven failure and the weakest TLS version
in existence.


-Martin