Re: [TLS] About encrypting SNI

[Nikos Mavrogiannopoulos <[e-mail]>]

On Tue, 2014-05-13 at 13:53 -0400, Daniel Kahn Gillmor wrote:
> On 05/13/2014 09:07 AM, Salz, Rich wrote:
> >>  Especially given that there's little value in encrypting SNI with[out] encrypting/securing DNS, associating the two has some nice mutually-motivating properties.
> > The “[out]” is the important missing part, I think.
> yes, indeed :)  But that's what the dns-privacy discussion is about.
> 
>   https://www.ietf.org/mailman/listinfo/dns-privacy
> If we don't offer a standard mechanism for protecting the
> confidentiality of SNI (at least against passive monitors) in upcoming
> versions of TLS, then the dns-privacy discussion is going to have
> serious trouble sustaining its work by an analgous "little value
> unless..." argument.  We shouldn't sabotage that work.
> The TLS WG needs to fix the SNI leak, and DNS confidentiality needs to
> be addressed by the DNS folks if we want to protect this information
> against passive eavesdropping.

Fixing the SNI leak is easy, just don't use SNI. The main issue is in
the TLS handshake which sends the certificates in plain. A fix for
passive eavesdroppers would require a new IPSec-style handshake. It
comes at a cost though. Load balancers and redirectors will need to
terminate TLS in order to redirect the traffic to the proper host.
Terminating TLS there would mean (a) the encrypted session isn't
terminated on the intended server but somewhere else, (b) user
authentication with TLS will be pretty much unusable for hosts behind
that type of systems, (c) software redirection of sessions (e.g.,
because a different process handles a different host or protocol - see
ALPN) will also become very difficult.

regards,
Nikos