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

[Sean Leonard <[e-mail]>]

On 11/11/2013 4:55 PM, Martin Rex wrote:
> Ralf Skyper Kaiser wrote:
>
>> SNI can be transmitted encrypted and should be transmitted encrypted (see
>> recent plenary sessions at IETF88).
> What you seem to want to do is not SNI, but something else.
>
>
>> Martin, with your argument why should we fix anything at all in any product
>> or design?
> Don't fix it if it ain't broken.  SNI is not broken.
>
>
>> The proposed solution FIXES passive pervasive surveillance in TLS 1.3.
> [...]
>> Let's make pervasive passive surveillance harder.
> To me, this is self-illusion.  Why should NSA look at SNI at all?

Okay so here's the thing. A passive observer of the network can probably 
figure out that a particular TLS connection is intended for a particular 
hostname.

The client and server IP addresses are in the clear. No question.

To figure out the server's IP address from its hostname, the client must 
do a DNS lookup. This will be in the clear. Even if a particular client 
doesn't go over the (surveiled) public Internet to do the DNS lookup 
(due to local DNS server caching), for any nontrivial amount of 
connections, the DNS record will float through the public Internet in 
the clear at some point.

Thus an eavesdropper can easily correlate the reverse lookup, IP address 
-> hostname(s), in a minimal amount of time.

So, the fact that SNI is in the clear, is not really leaking additional 
information that a passive (but consistent and pervasive) eavesdropper 
would have figured out in the first place.

Unless of course you are using SNI to stuff in side-channel information 
(i.e., something other than a hostname)...but then you are not obeying 
the SNI protocol in the first place.

FWIW, I would prefer that all metadata (whether SNI or otherwise) not be 
in the clear. But as Martin Rex said, it being in the clear is not fatal 
to security.

-Sean