Re: [TLS] In support of encrypting SNI

[Seth David Schoen <[e-mail]>]

Dan Blah writes:

> Many of the discussions and subsequent decisions that move forward here
> are incredibly important to OTF's work. As such, I wanted to toss in our
> support for the coming version of TLS 1.3 to "Encrypt as much of the
> handshake as possible". This should include all of the metadata and
> TLS-layer routing information. We think by default is important for
> those threatened users we work closely with.

I would like to add the Electronic Frontier Foundation's support to
this view.  We have been learning so much recently about the privacy
significance of communications metadata.  At the time that many basic
Internet protocols and mechanisms were created, the cutting edge of
privacy was providing merely optional mechanisms to protect session
content.

We can see today that protocols that were designed with good engineering
intentions in their time are nonetheless leaking a lot of data that
is, in fact, sensitive.  That includes leakages of unique device and
user identifiers, which can even be used to track people's physical
whereabouts, as well as leakages of other endpoint identifiers -- like
the name of a virtual host.  In the modern era, it's good practice to be
extremely aggressive about minimizing cleartext data leaks in protocols.
SNI and other parts of the TLS handshake are one part of that, and it
is worth focusing attention on them to try to protect as much user
information as possible.

The TLS handshake is a target of scrutiny for censorship as well as
surveillance purposes.  This is particularly significant since some
providers have started to host resources for extremely disparate sites
and services (creating much more threshold uncertainty for a censor about
what a particular user is actually trying to access).  Middleboxes are
already able to use SNI for censorship purposes today.

It's true that equivalent information can leak in other ways, such
as through DNS queries.  But as Alyssa Rowan previously noted here,
the existence of multiple parallel information leakage sources risks
creating a "circular argument of doom and defeat" when attempting to fix
any of them -- where we might not try to fix DNS query privacy because of
the SNI problem, and vice versa!  And even today, some adversaries may
well be on-path for observing the TLS handshake but not for observing
DNS queries, and vice versa.

SNI -- and the rest of the handshake -- isn't the most privacy-sensitive
source of information leaks in Internet protocols.  (That honor might
go to MAC addresses, which allow passively recognizing the presence of
particular devices at the data link layer, or to any of several mechanisms
at the HTTP layer that allow second or third parties to recognize a
particular client over time.)  But it's still worth trying to address
these information leaks in a modern secure communications protocol.

-- 
Seth Schoen  <[e-mail]>
Senior Staff Technologist                       https://www.eff.org/
Electronic Frontier Foundation                  https://www.eff.org/join
815 Eddy Street, San Francisco, CA  94109       [phone] x107