Subject: [TLS] In support of encrypting SNI

From: Dan Blah <[email-masked]>
Date: Wed, 14 May 2014 20:33:07 +0100

Heya all,

To start, I really appreciate what you all are up to here. In
particular, the discussions with outcomes having an indirect or direct
impact on Internet freedom and technology that advance human rights broadly.

I'm writing in both my personal and professional capacity as managing
director of the Open Technology Fund. We offer direct and in-kind
support to global individuals and organizations confronting the many
threats to Internet freedom globally. It's likely you're familiar with
some of the 30 odd projects we provide direct support to including Tor,
Open Whisper Systems, and Cryptocat. You may know we offer in-kind
security and privacy audits to a much broader set of efforts we don't
support directly such as TrueCrypt or OpenPGP.js. You may not know we
offer in-kind access to secure cloud infrastructure and maintain support
for an Internet freedom Digital Emergency Response Team. You don't know
about the 30+ websites and numerous individuals we support who work to
maintain an inch of free expression from inside countries with
repressive regimes that restrict access to online freedom.

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.

We know this is just a start of a solution and only one aspect of it. We
know that significant work needs to be done elsewhere to prevent passive
or active tracking, censorship based on DNS, difficult website
fingerprinting techniques, and other key threats to Internet freedom.
Even those all addressed, in some situations we will fall short of
aggressive censors. Despite that, it's a start, it's forward movement,
and omitting these features in TLS 1.3 will make it that much easier for
censors to silence the voice of journalists, human rights defenders,
NGOs, activists, and bloggers around the world.

Censorship is real, and we should fight against it where we can. If you
smarter folks than I make these changes in TLS 1.3, valid recipients of
the online data will be able to handle incoming traffic however they
wish, but the networks or repressive governments in-between should not
be able to block or degrade service based on plaintext metadata.

Daily, we are witness to censorship occurring at the service level in
every corner of the world. The effects are felt by small website hosts
to Google and Facebook. Leaving some of this information in plaintext
may seem insignificant to many here but it's of significant value to
those who would suppress free expression online. Surely any crucial
increase of free expression we here can give others out weighs
technicalities.

Thanks in advance!
-- 
Dan Blah
pgp 0x36377134

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 14 May 2014 16:35:01 -0400

Dan, thanks for writing the passionate and detailed note.

> . Surely any crucial increase of free expression we here can give others out weighs technicalities.

I just want to let you know that, somewhat sadly, I disagree with the quoted sentence, and I'm not alone.  (Even the author of the "it's an attack" RFC has said that barring good technical solutions we're unlikely to do it.) Encrypting the handshake will not prevent passive surveillance. From a technical view, it's not clear it provides enough privacy to justify the non-inconsiderable costs.

	/r$
 
--  
Principal Security Engineer
Akamai Technologies, Cambridge, MA
IM: [email-masked]; Twitter: RichSalz

---

From: Seth David Schoen <[email-masked]>
Date: Wed, 14 May 2014 13:47:07 -0700

> 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  <[email-masked]>
Senior Staff Technologist                       https://www.eff.org/
Electronic Frontier Foundation                  https://www.eff.org/join
815 Eddy Street, San Francisco, CA  94109       +1 415 436 9333 x107

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 14 May 2014 23:01:02 +0100

On 14/05/14 21:35, Salz, Rich wrote:
> I just want to let you know that, somewhat sadly, I disagree with the
> quoted sentence, and I'm not alone.  (Even the author of the "it's an
> attack" RFC has said that barring good technical solutions we're
> unlikely to do it.) Encrypting the handshake will not prevent passive
> surveillance. From a technical view, it's not clear it provides
> enough privacy to justify the non-inconsiderable costs.

I think you've slightly misinterpreted me there Rich, I'll try be
clearer:-)

Yes we do need a good technical solution and we don't yet have
one written down. There is an of course obvious technical solution
for at least passive attacks, but that does have the significant
and real negative aspect that you pointed out, so is perhaps not
good enough by itself.

I'm also less concerned with monetary costs (most who are running
large numbers of TLS instances like you guys could afford some
monetary costs:-) but more with the architectural problem that the
TLS stacks running in different VMs would not be willing to agree
on SNI protection algorithms etc. should a solution require those
to be the same across all VMs. But I'm not at all clear that's
insurmountable really.

So same point I made before: we need folks who want this to put
in the work to write down their solutions. (And the corollary is
that if we don't figure out how to protect SNI then we need to
document why fairly well, not necessarily in an RFC, but in some
kind of referenceable thing.)

Cheers,
S.

PS: And again, wearing no hats for this conversation.

> 
> /r$
> 
> -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM:
> [email-masked]; Twitter: RichSalz
> 
> _______________________________________________ TLS mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/tls
>

---

From: Watson Ladd <[email-masked]>
Date: Wed, 14 May 2014 15:15:33 -0700

Dear all,
There are several different proposals for encrypted SNI floating
around, and I'd like to take the time to summarize them:
1: Use an unauthenticated channel to encrypt the handshake. Adds an
extra round trip, unless server goes first.
2: Use an unauthenticated channel, feed key into inner handshake so
MITM gets detected.
3: Have DNS records contain a key to use to encrypt the handshake, key
shared across sites hosted under the same IP address
4: Encrypt the handshake with a key that is per-site

JFK is out because that involves trusting the load balancer. 4 and 3
involve administrative action by websites, and depend on DNSSEC
deployment: they are unlikely to be widely deployed. 2 is probably the
best bet, but it has a real problem: the load balancer needs to send
the key from the channel to the server, necessitating architecture
changes.

This leaves 1 as a universally deployable solution. It doesn't get
very much done for the work it does. It's better than what we have
now, but not much.

As for algorithms, I think there is much less disagreement than
commonly believed: the wrapper for the handshake does not affect the
security of the handshake.

Sincerely,
Watson Ladd

---

From: Fabrice <[email-masked]>
Date: Wed, 14 May 2014 23:23:24 -0700

> On May 14, 2014, at 15:15, Watson Ladd <[email-masked]> wrote:
> 
> Dear all,
[...]
> [...] 4 and 3
> deployment: they are unlikely to be widely deployed.

If a comprehensive solution to the surveillance problem also involve changes to plug leaks by DNS, wouldn't it be reasonable that the TLS portion of the solution  depends on the DNS bits being deployed as well?

-- Fabrice

---

From: "Christian Huitema" <[email-masked]>
Date: Wed, 14 May 2014 23:30:04 -0700

> If a comprehensive solution to the surveillance problem also involve
changes to
> plug leaks by DNS, wouldn't it be reasonable that the TLS portion of the
solution
> depends on the DNS bits being deployed as well?

This is a bit close to the "your side of the boat is leaking more than mine"
argument. Let's plug both leaks, and not have each wait for the other.

-- Christian Huitema

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 15 May 2014 00:34:04 -0600

> If a comprehensive solution to the surveillance problem also involve changes to plug leaks by DNS, wouldn't it be reasonable that the TLS portion of the solution  depends on the DNS bits being depl…

Or, to look at it slightly differently: we can deploy TLS with an
encrypted handshake that is protected against passive monitoring even in
the absence of DNSSEC.  And when DNSSEC is available, it becomes
possible to detect or prevent active attacks.

There's no reason to wait for DNSSEC to become available to start to use
mechanisms that would protect against passive monitoring in its absence.

	--dkg

---

From: Robert Ransom <[email-masked]>
Date: Wed, 14 May 2014 23:38:40 -0700

> argument. Let's plug both leaks, and not have each wait for the other.

That's what Fabrice was suggesting.  (Specifically: the pieces of text
quoted in that message describe solutions to the TLS leaks which
depend on having extra information pre-distributed in DNS.)

Robert Ransom

---

From: Watson Ladd <[email-masked]>
Date: Thu, 15 May 2014 20:32:47 -0700

> depend on having extra information pre-distributed in DNS.)

It's a little more subtle than that. Options 3 and 1 have the same
security absent DNSSEC, but different performance, with Option 1
requiring an extra round trip. However, Option 3 requires
administrative action on the part of a website to work. The payoff
depends on DNSSEC.

So right now I see Option 1 or 3 as our best bet, with very limited
real world impact.

Sincerely,
Watson Ladd

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

---

From: S Moonesamy <[email-masked]>
Date: Sat, 17 May 2014 08:15:35 -0700

Hi Dan, Michael,
>threats to Internet freedom globally. It's likely you're familiar with

The message is from blah.is.  I cannot determine whether there is any 
association with the "Open Technology Fund".

>NGOs, activists, and bloggers around the world.

The above seems like a political matter [1].

At 21:55 14-05-2014, Michael Carbone wrote:
>We hope the IETF considers the needs of at-risk users as well as of all
>of us targeted by pervasive monitoring in supporting encrypted TLS
>handshakes by default.

It would be safer for the at-risk users if they ensured that those 
needs are taken into account in the final version of the relevant 
specification.

Regards,
S. Moonesamy

1. It could be argued that leaking the information should be 
considered as part of the (IETF) security considerations.

---

From: Michael Carbone <[email-masked]>
Date: Sat, 17 May 2014 15:54:49 -0400

S Moonesamy:
> It would be safer for the at-risk users if they ensured that those needs
> are taken into account in the final version of the relevant specification.
> 
Hi S. Moonesamy,

I'm not exactly sure what you are suggesting, but that's why Access is
here -- to help highlight the importance of this proposal to the folks
who are actively involved in the discussion and consideration of
proposals for the specification.

Waiting and assuming that an encrypted TLS handshake by default will
appear in the TLS 1.3 specification seems like a non-ideal approach,
given that without discussion, a proposed implementation, and support,
it will likely not get there. We recognize honing a proposed
implementation is a lot of work and we want to support those who are
currently discussing and drafting one. It is worthwhile, and the
real-world impact will be tangible.

It's difficult for these communities to ensure their needs are taken
into account given that they are non-technical, unaware of the IETF, and
obviously not part of the process. We want to make sure such users are
protected as much as possible by the default behavior of the
communications methods they rely on, hence the importance of having the
handshake be encrypted by default.

Let me know if I missed the thrust of your concern, happy to continue
the discussion off-list.

Michael

> Regards,
> S. Moonesamy
> 
> 1. It could be argued that leaking the information should be considered
> as part of the (IETF) security considerations.

-- 
Michael Carbone
Manager of Tech Policy & Programs
Access | https://www.accessnow.org

GPG: 0x81B7A13E
Fingerprint: 25EC 1D0F 2D44 C4F4 5BEF EF83 C471 AD94 81B7 A13E

---

From: S Moonesamy <[email-masked]>
Date: Sun, 18 May 2014 10:12:57 -0700

Hi Michael,
>real-world impact will be tangible.

I agree that waiting and assuming that the outcome of a specification 
would be favorable is a non-ideal approach.

>obviously not part of the process. We want to make sure such users are

Yes.

Although it might not be the intent the message came out as designing 
a TLS specification to bypass censorship for political 
reasons.  There were two organizations [1] which posted comments 
along those lines.  I suggested framing the comments as technical 
input and avoid the political advocacy angle.

Note that I am okay with encrypting the SNI as the average user would 
expect that the information being sent can only read by the endpoint 
on the other side.

Regards,
S. Moonesamy

1. I am aware of how affiliation works in the IETF.  I used the word 
in my explanation for clarity.