Subject: [TLS] SNI privacy compromise: only for resumption in 1.3

From: Nico Williams <[email-masked]>
Date: Sat, 17 May 2014 22:39:44 -0500

How about only providing SNI privacy in resumption handshakes only in 1.3?

Clients that really want it would have to do an extra handshake before they
could use a session with SNI.

To do this right and extensibly to a future with DNSSEC with privacy we'll
need an extension that is always present (even in initial, non-abbreviated
handshakes, and even when not actually desired) whose payload is intended
to identify an encryption key (but without identifying the server's
name, such as a hash of the key found with DANE, or a key derived from the
session key of the resumption ticket) and an encrypted payload,
with plaintext padded to obfuscate name lengths, or maybe a hash of the
desired name.

The server should send its certificate in an encrypted -also always
present- extension in its reply.  The key for encrypting the reply
should be derived from the new session's session keys.

The additional cost of this for resumption should be marginal (only a bit
of extra symmetric key crypto).  And it gives us a way to also do it right
in the future for non-resumption handshakes.

Nico
--

---

From: Watson Ladd <[email-masked]>
Date: Sat, 17 May 2014 22:04:41 -0700

> could use a session with SNI.

How does this help? I can think of one way: the ticket is marked with
the name of the server that sent it somehow. Maybe this addresses the
middlebox issue. However, for anti-censorship this is useless as the
SNI is sent on the first handshake, and so can be used to censor a
connection: you don't ever get to resume.

> handshakes, and even when not actually desired) whose payload is intended to
> identify an encryption key (but without identifying the server's name, such
> as a hash of the key found with DANE, or a key derived from the session key
> of the resumption ticket) and an encrypted payload, with plaintext padded to
> obfuscate name lengths, or maybe a hash of the desired name.

What stops the censor from looking up the data that will be sent in
the identification tag? Or are you suggesting something along the
lines of Option 3, where the key corresponds to IP address/machine?

>
> The server should send its certificate in an encrypted -also always present-
> extension in its reply.  The key for encrypting the reply should be derived
> from the new session's session keys.

Why does a resumed connection require presentation of certificates? A
resumed connection has a key that (if TLS had been designed correctly)
would only be known by the server and the client. I assume we are
fixing this in TLS 1.3. Or were you discussing the general case of
encrypted SNI, where we do need to protect the entire handshake
because of the places names can appear.

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

---

From: Yoav Nir <[email-masked]>
Date: Sun, 18 May 2014 11:38:17 +0300

On May 18, 2014, at 6:39 AM, Nico Williams <[email-masked]> wrote:

> Clients that really want it would have to do an extra handshake before they could use a session with SNI.
> 
> To do this right and extensibly to a future with DNSSEC with privacy we'll need an extension that is always present (even in initial, non-abbreviated handshakes, and even when not actually desired) whose payload is intended to identify an encryption key (but without identifying the server's name, such as a hash of the key found with DANE, or a key derived from the session key of the resumption ticket) and an encrypted payload, with plaintext padded to obfuscate name lengths, or maybe a hash of the desired name.
> 
> The server should send its certificate in an encrypted -also always present- extension in its reply.  The key for encrypting the reply should be derived from the new session's session keys.

Which certificate does the server send?  If the server always sends the same certificate, there’s no point in SNI privacy.

---

From: Tom Ritter <[email-masked]>
Date: Sun, 18 May 2014 10:49:29 -0400

Having SNI privacy in resumption or the 0-RTT will probably only make
things worse, as it becomes a fingerprinting methodology for the
attacker. I force you to connect to subversive.github.io and if you do
0-RTT or resume, I know you've visited there before.  Instead what you
want is the client to behave the same way as if you had never visited
there before. If the client wants to protect SNI it will either look
up a key via an out-band-of-band method (to keep 1-RTT, this could be
in DNS in a B-Record as suggested by Eric Nygren[0]) or via an in-band
mechanism using 2-RTT.

> lines of Option 3, where the key corresponds to IP address/machine?

I believe (or at least I'm rewriting it in my mind) that he is. The
Key/KeyID is used for multiple sites, so it protects SNI.  A site and
the middlebox/target of the A/B/CNAME record (which might be the same
person) COULD 'collude' to make the Key/KeyID into an SNI equivalent,
but I think I'm okay with that because if they're willing to leak the
information for deployment reasons, they will probably do so in some
way - you can't force them to protect it everywhere, you can only make
protecting it the default.  Sites that want to protect it will protect
it, and the encrypted-SNI and SNI-equivalent-KeyID flows look
identical on the wire so the censor actually has to go to the trouble
of figuring out which is which.

-tom

[0] http://www.ietf.org/proceedings/interim/2014/05/15/tls/slides/slides-interim-2014-tls-1-0.pdf

---

From: Russ Housley <[email-masked]>
Date: Sun, 18 May 2014 11:35:40 -0400

Nico:

I do not understand your suggestion.  When I guess at your meaning, TLS 1.3 seems more frail.  So, I will stop guess and ask you to explain.

Russ

On May 17, 2014, at 11:39 PM, Nico Williams wrote:

> The additional cost of this for resumption should be marginal (only a bit of extra symmetric key crypto).  And it gives us a way to also do it right in the future for non-resumption handshakes.
> 
> Nico
> -- 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls