Subject: Re: [TLS] Encrypted SNI (was: Privacy considerations - identity hiding from eavesdropping in (D)TLS)

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 21 Sep 2015 08:32:50 -0700

On Fri 2015-08-28 09:22:52 -0700, Viktor Dukhovni <[email-masked]> wrote:
> So the client would now need to cache some session data by transport
> address, and other data by name and port.  That's rather complex.

This is already done by HTTP/2 clients, since they can access multiple
servers at the same address:port combination.

> And how often will the same client visit multiple servers at the
> same transport address?

*.github.io, *.blogspot.com, massive CDNs, etc.  It's a common pattern.

> I don't really see this as viable or worth the effort.

I disagree -- the metadata leaked to a passive attacker by mandatory SNI
is a valuable signal.  It is worth trying to protect it.

> I don't think SNI hiding is viable without encryption at the
> transport or network layers.

any encrypted SNI is effectively acting as a shim for transport
encryption, yes.  Then again, TLS is itself "transport layer security",
so we should try to provide it at least as an option.

> And there's still a metadata leak via DNS which may prove difficult to
> address.

The DNS community is working to address the DNS leak in DPRIVE.  The TLS
community should be working to fix its own part of the metadata leak.

          --dkg

---

From: Jacob Appelbaum <[email-masked]>
Date: Tue, 22 Sep 2015 17:39:51 +0000

> is a valuable signal.  It is worth trying to protect it.

I agree - this metadata is usable as a selector for automated
surveillance and for automated exploitation.

> so we should try to provide it at least as an option.

In an ideal world: using ephemeral keys, we must be able to have usage
of the protocol that is selector free.

> community should be working to fix its own part of the metadata leak.

Agreed, strongly.

All the best,
Jacob

---

From: Dave Garrett <[email-masked]>
Date: Tue, 22 Sep 2015 13:57:06 -0400

I've been effectively convinced that encrypted SNI can only provide mild protection in some specific instances, and usually only provides a false sense of security. That said, if someone does want to design a system, I can think of a relatively easy route forward here. The TLS 1.3 spec will be introducing Server Configuration Extensions (different from Hello extensions). Encrypted SNI could be implemented by creating a config extension to provide a second semi-static key to be used for SNI encryption. This would require server configurations be distributed through some out-of-band route, but this will probably already be desired and is not really avoidable if you want to encrypt something in the first-flight, like SNI. Without this, at least repeat connections could have SNI encrypted. This ESNI key would be shared across virtual servers and be issued by the host. The same server_name hello extension would be used, but it'd just be encrypted for hosts that support it.

The even simpler route is to just put the SNI extension in EncryptedExtensions when possible, but that requires sharing one 0RTT key across all virtual servers on the host. There's probably plenty of situations where this is fine, but I think it'd be better to just generalize things to have a second key and avoid problems here, at this point.

Dave

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Tue, 22 Sep 2015 14:20:40 -0400

> surveillance and for automated exploitation.

I agree with Jake and DKG wholeheartedly.

I'd add that in addition to surveillance and exploitation, cleartext
SNI will be useful for censors at various scales... the same property
that it's useful for (distinguishing which domain at an endpoint a TLS
conversation is for), can be used to impair or drop flows.

I realize there is a small minority of people that participate in TLS
WG that feel very strongly about designing a way to have encrypted
SNI, but I'd really hope that we can find a way to do it, and that
it's not considered too massive of an effort.

The uses in which we would want to harden TLS connections against
surveillance, exploitation, and censorship will seem to only grow, and
having it baked into the infrastructure (and done well) will mean we
will have much more deployed ability to resist these kinds of network
attacks.

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

-- 
Joseph Lorenzo Hall
Chief Technologist
Center for Democracy & Technology
1634 I ST NW STE 1100
Washington DC 20006-4011
(p) 202-407-8825
(f) 202-637-0968
[email-masked]
PGP: https://josephhall.org/gpg-key
fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 22 Sep 2015 18:37:33 +0000

We discussed this before.  Not that we can't discuss it again.  Here's a link to slides I presented at the Toronto Interim in July 2015.

	https://drive.google.com/file/d/0B8YgrWYHqacSV2hnZmR3VjJtRUk/view?usp=sharing

---

From: Nick Mathewson <[email-masked]>
Date: Fri, 25 Sep 2015 09:49:47 -0400

>         https://drive.google.com/file/d/0B8YgrWYHqacSV2hnZmR3VjJtRUk/view?usp=sharing

Thanks for that link, Rich!

Please forgive me if my analysis has already been gone over, but I
believe that there are at least three problematic aspects in the
argument as presented in your slides.

1) Entrenchment of codependent vulnerabilities

This is a strong antipattern in security design, and it's been
practiced by some of the great minds of the field, but I think it's
fundamentally mistaken. Here's how it works:

There are two systems, A and B.  Each has a problem that enables some
kind of attack. The people who maintain system A say: "There is no
point in fixing A, because any attacker who breaks A could achieve the
same results via B."  But the people who maintain system B say: "There
is no point fixing B because any attacker who breaks B can achieve the
same results via A."

Both groups are using solid logic: neither one of them would
materially improve user security by fixing the vulnerability in their
system.  The Codependent Vulnerability antipattern arises when no
progress is ever made, because each group decides that the problems
outside its control will probably never be fixed.

In your slides, I see several instances of codependent vulnerabilities:

a) Improved DNS security vs Encrypted SNI

The lack of security in current DNS usage is taken to justify not
improving SNI privacy. But in discussions about DNS privacy,
vulnerabilities in other protocols are frequently taken as
justification for not improving DNS privacy.

b) Traffic analysis vs encryption

Traffic analysis is indeed strong today, but it's not omnipotent, and
good research on resisting it is happening all the time.  But if we
take the weaknesses of TLS against traffic analysis a a permanent
feature of the world, then such research will have less opportunity to
bear fruit, since TLS will entrench the problems that
anti-traffic-analysis research cannot yet solve.

c) Technical attacks vs rubber-hose attacks

See point 2 below.

2) Attacks are not equally costly and do not scale equally well.

It's not sufficient to say "This defense will not render the attack
impossible; therefore it is useless"; we also need to consider whether
the defense will render the attack _more expensive_.

Even for regimes unconcerned with fair play and regimes with
significantly intrusive attitudes to civil liberties... intimidating
citizens, applying political pressues, and backdooring infrastructure
are not zero-cost operations.  In nearly all cases, ithese attacks are
more difficult and costly than simply reading bytes off the wire.

3) Censorship vs surveillance.

The analysis in the slides is concerned with attackers against privacy
rather than attackers against availability.  But IMNSHO, both kinds of
attacker are a significant threat to human rights.

Unencrypted SNI makes a censor's job extremely easy.  In today's TLS,
it's trivial to block targeted domains hosted at a provider without
blocking ones where the censors consider access desirable.  Encrypting
SNI would make this kind of blocking more difficult and technically
expensive.

To be fair, encrypted SNI would probably make trouble for providers
who host some censored and some uncensored services.  Plaintext SNI
does make it easier for censors to be selective, and thereby makes it
easier for hosting providers to avoid conflicts and drama.

best wishes,
-- 
Nick Mathewson
<[email-masked]>

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 25 Sep 2015 15:27:50 +0000

Thanks for your detailed and thoughtful review.

It's all trade-offs.  In previous emails on this thread I acknowledged the co-dependant issue, by calling out dkg's excellement statement of it.

At the TLS interim earlier this week, Brian Sniffen (from Akamai) started a proposal that makes SNI-encryption something that can be deployed and tested on the Internet in TLS 1.3.  So we'll see if it gets used and works.  The earlier slides notwithstanding, it's something we (those of us at Akamai) would really like to see.

---

From: [email-masked] (Martin Rex)
Date: Fri, 25 Sep 2015 19:00:03 +0200 (CEST)

Salz, Rich wrote:
> 
> At the TLS interim earlier this week, Brian Sniffen (from Akamai) started
> a proposal that makes SNI-encryption something that can be deployed and
> tested on the Internet in TLS 1.3.  So we'll see if it gets used and works.
> The earlier slides notwithstanding, it's something we
> (those of us at Akamai) would really like to see.

I haven't been tracking the TLSv1.3 proposals -- but whatever you do
in the area of encrypted SNI, please ensure that padding *WILL* be used,
so that two encrypted server names, that happend to differ by length,
will not remain easily distinguishable.

-Martin

---

From: [email-masked] (Martin Rex)
Date: Fri, 25 Sep 2015 19:10:37 +0200 (CEST)

> will not remain easily distinguishable.

Because it is not necessarily immediately obvious, you will need
padding also for the Server Certificate handshake messages.
And, because the key exchange is side-effected by properties of
the Server Certificate, you may additionally need padding for the
ServerKeyExchange and ClientKeyExchange handshake messages, so
that the protocol doesn't leak of one of the service uses
an RSA certificate and the other uses an ECDSA (or EdDSA) certificate.

-Martin

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 25 Sep 2015 17:33:30 +0000

Various paddings (is that a word?) will be needed, but the ability to pad things is also in TLS 1.3.  We think all the necessary TLS protocol bits are present.

--  
Senior Architect, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

---

From: Dave Garrett <[email-masked]>
Date: Fri, 25 Sep 2015 14:11:31 -0400

> an RSA certificate and the other uses an ECDSA (or EdDSA) certificate.

This sounds like a good argument to come up with a default padding scheme for all handshake messages for even clients that don't use application data padding.

Dave

---

From: "Dang, Quynh" <[email-masked]>
Date: Fri, 25 Sep 2015 18:20:08 +0000

How about making fixed length(s) for each message type, then pad it with 0x01 then optional 0x00s?

Quynh. 

________________________________________
From: TLS <[email-masked]> on behalf of Dave Garrett <[email-masked]>
Sent: Friday, September 25, 2015 2:11 PM
To: [email-masked]; [email-masked]
Subject: Re: [TLS] Encrypted SNI (was: Privacy considerations - identity hiding from eavesdropping in (D)TLS)

Dave