Subject: [TLS] draft-rescorla-tls13-new-flows-01 - Thoughts post-meeting

From: Michael StJohns <[email-masked]>
Date: Sun, 16 Mar 2014 13:21:36 -0400

During the TLS meeting EKR talked about encrypting most of the protocol 
negotiation, and noted that the primary use case for that was the SNI.  
Someone else noted, that the SNI was often used as routing information 
by distributor boxes and might be problematic to encrypt.  Further 
discussion ensued 
(http://www.ietf.org/proceedings/89/minutes/minutes-89-tls) leading to a 
hum on protecting the SNI that was pretty much down the center of do/don't.

After thinking about it for a bit - how about simply hashing the data in 
the SNI? Ideally calculated with a prefix of a random value that's also 
sent along in the SNI so the same hash isn't sent over and over?

struct {
      opaque tag[8];
      opaque hash<16,24,32, etc>; /* hashed name of the host being 
connected to */
} HashedSNI;

The middle distributor box would need to be told which names it was 
forwarding, but only that.  It would calculate hashes using the 
concatenation of the tag and the names it knows, and compare the hash 
value to the hash in the HashedSNI to figure out the forwarding.

This is not "perfect security" by any means, but provides a bit of 
on-the-wire privacy.   The attacker would have to know the set of names 
at that IP address to determine which name was being contacted.  It does 
have the virtue that it doesn't require shared keys between either the 
client and server, or between the server and middle box.

Mike

---

From: Watson Ladd <[email-masked]>
Date: Sun, 16 Mar 2014 11:12:33 -0700

On Sun, Mar 16, 2014 at 10:21 AM, Michael StJohns
<[email-masked]> wrote:
> Someone else noted, that the SNI was often used as routing information by
> distributor boxes and might be problematic to encrypt.  Further discussion
> ensued (http://www.ietf.org/proceedings/89/minutes/minutes-89-tls) leading
> to a hum on protecting the SNI that was pretty much down the center of
> do/don't.
>
> After thinking about it for a bit - how about simply hashing the data in the
> SNI? Ideally calculated with a prefix of a random value that's also sent
> along in the SNI so the same hash isn't sent over and over?

>From time to time, people have a privacy issue like NSEC. Someone
comes along and says
"I know! we'll use hashing." and we get NSEC3.

Do you know how many SHA256 calls per second off-the-shelf commercial
ASICs can do? It's about 155 million per second per dollar.

Do you know how many hostnames there are? Well, theoretically many,
but most are made human-readable: the entropy is much lower than the
length and alphabet would suggest.

The attacker can determine which name is being contacted with a few
weeks of calculation. Once it has the hostnames,
figuring out what is going on is quick. This already exists in the
form of the nsec3walker tool.

Sincerely,
Watson Ladd

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 16 Mar 2014 12:41:12 -0700

On Sun, Mar 16, 2014 at 11:12 AM, Watson Ladd <[email-masked]> wrote:

> the

Good point.

If anything, this analysis is too pessimistic. In the most common case, the
attacker will have some idea of the set of SNIs being served by a given
server, e.g., because TLS 1.2 SNIs are in the clear. At that point, as you
note above, the problem of determining which of the small set of SNIs
is being used is much easier.

-Ekr

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

---

From: Michael StJohns <[email-masked]>
Date: Sun, 16 Mar 2014 16:40:49 -0400

> "I know! we'll use hashing." and we get NSEC3.
NSEC3 was not a privacy issue item, it was a database walking item.

> ASICs can do? It's about 155 million per second per dollar.

Ok - let's inject a little bit of financial analysis.

Two questions:

1) What's the cost of making the first attack (not the delta, but the 
minimum cost to an attacker to build something to do what you're talking 
about, PLUS the cost of actually acquiring the data on the wire)?

2) What's the value of the first piece of data to the specific attacker?

My point is that unless there is specific value to the attacker, and 
that value is greater than the cost to the attacker of making the 
attack, then the attack won't happen.

Two further questions:

3) What, exactly, is the value of the privacy of the query data to the 
querier and how much does that value degrade over time once the query 
has been made?

4)  Just how much can be spent on protection before the protection costs 
exceed the value of the data?

and two further questions.

5) Are the anticipated attacks general (shot gun) or targeted?

6) If targeted, does encryption provide sufficient protection or could 
the data be gotten for similar costs via other attacks?

It was clear from the WG meeting that there wasn't consensus to add 
encryption across the board - whether from a disagreement on need or 
whether the mechanism EKR proposed was the way to go or possibly 
something else.  That said, if this is about trying to protect against 
well funded attackers, encryption in not a panacea.  If this is about a 
casual eavesdropper, then maybe a simpler solution is reasonable.

> weeks of calculation.

Weeks?  Oh - you're worried about a shotgun and national actor approach, 
rather than the typical attacker. OK.

In any event, there are any number of ways to increase an attackers work 
factor substantially without increasing the work factor for someone that 
already knows the small set of answers.  Think of it as a DNS arms race 
and we win if we make them spend more than they get back in value.  You 
used 155m hashes per dollar - so if we increase the work factor to say 
500m hashes to find a name, then it costs $3 per query to resolve to the 
names. How many connections per day are there?

Later, Mike

> Once it has the hostnames,

---

From: Erik Nygren <[email-masked]>
Date: Sun, 16 Mar 2014 17:31:04 -0400

It's unclear how much harder it makes this for the anti-privacy attacker,
but it certainly makes it easier for attackers trying to attack a middle
distributor/demuxer box.

Pros helping the passive anti-privacy attacker:  they also have server IP
address to constrain the problem space by, plus TLS 1.2 SNIs so if there
are a 100k hostnames behind the middlebox then that's their search space.

Pros helping the DDoS attacker: they can just send random hash+opaque
values.  The middle box needs to then calculate the hash for all of the
hostnames (eg, perhaps 100k in the same scenario above).

As such, it is actually cheaper for the anti-privacy attacker than it is
for the middle/demuxer box to handle this traffic under a DDoS scenario and
about the same cost (but still quite expensive!) under normal traffic
flows.  This likely incentives the middle/demux operator to use more IPs to
help protect themselves which also makes life easier for the attacker (and
chews up IPv4 space).

          Erik

---

From: Michael StJohns <[email-masked]>
Date: Sun, 16 Mar 2014 19:47:19 -0400

On 3/16/2014 5:31 PM, Erik Nygren wrote:
> Pros helping the passive anti-privacy attacker:  they also have server 
> IP address to constrain the problem space by, plus TLS 1.2 SNIs so if 
> there are a 100k hostnames behind the middlebox then that's their 
> search space.
>
> values.  The middle box needs to then calculate the hash for all of 
> the hostnames (eg, perhaps 100k in the same scenario above).

I don't disagree with any of your points (but there's always a tradeoff 
between DOS protections and negotiation protections), but I wanted to 
focus on the 100K.

The question is - if the SNI is encrypted from the client to the end 
system, how do the end systems communicate with the middle box to pass 
on their key info and keep it up to date - not on a per-box 100K basis, 
but on a 100K times the number of connections per box?

I think what we're getting to is that if we have a system where there is 
a middle box, then neither of these approaches makes a lot of sense for 
the scale you're talking about?

Mike

---

From: Tom Ritter <[email-masked]>
Date: Sun, 16 Mar 2014 18:43:17 -0700

> negotiation, and noted that the primary use case for that was the SNI.

What about protecting the certificate sent by the server?
What about protecting supported ciphersuites and extensions listed -
taking steps towards protecting what user agent is being used?
What about client certificates - protecting identity of the client?
What about extensions? SRP Data, Client/Server Auth data, Padding?
If we had this before, the DHE exchange would be protected and we
wouldn't be exposing 1024 DH all over the place.

If we spend all our time focusing on trying to protect individual
components, we'll find arguments against any of them.  I'd much rather
start from the perspective of protecting everything and address
problems on an individual basis.  When building a cryptographic
protocol you don't choose the smallest security margin you can think
of for the application.

-tom

---

From: Watson Ladd <[email-masked]>
Date: Sun, 16 Mar 2014 21:23:17 -0700

Dear Mr. StJohns,

Suppose you work at the Chinese Ministry of Truth, in the department
of web truthmaking, domain forgetting division.

Right now, if you want to ensure HTTP content is in conformance with
the truth you simply scan for the Host header and check against a
list.

For HTTPS life could get nasty. But luckily we decided to put SNI
information on the outside, so you can see if that connection needs to
go down the memory hole.

Now you hear about this TLS 1.3 coming along, and how it obfuscates
SNI. So you present the following design to your boss:
1: Each device on the filtering maintains a global IP->[Hosts] mapping.
2: When an obfuscated SNI comes along, you check against all hosts in
the mapping
3: If it is marked as untruthful block
4: If unknown, transmit it to a dedicated cracking machine.

Within a week the cracking machine is likely to figure out what the
hostname is, at which point it can be added to the list. If the agents
watching the spreading of untruth see a domain, we can just add it.
The computational cost will never exceed that of the hosting device.

Your proposal doesn't stop censorship or even make it more expensive.
It doesn't hide visits to websites effectively if the attacker is
interested in checking against a big list. It doesn't accomplish any
of the goals we need it to.

Sincerely,
Watson Ladd

---

From: Alyssa Rowan <[email-masked]>
Date: Mon, 17 Mar 2014 07:30:00 +0000

On 16/03/2014 17:21, Michael StJohns wrote:

> The middle distributor box would

...have access to the keys if it's really owned by the same party.

Otherwise we're back to passive pervasive surveillance/censorship.

SNI needs to be _encrypted_ and we need to make sure that encryption
is resistant to matching against known-plaintext due to DNS lookups
and TLS 1.2 SNI currently being in cleartext (having not switched to
encrypted yet).

- -- 
/akr

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 17 Mar 2014 09:00:45 +0100

> information on the outside, so you can see if that connection needs to

I think this is a common misconception. SNI places the hostname in the
clear, but that was already available. It is present in plain in both
the DNS request and the certificate sent by the TLS server. SNI allowed
the server to properly select the correct certificate when
multi-hosting, but didn't really modify the existing privacy level.

What I believe is the actual privacy issue there, are the cleartext
certificates (client and server) in TLS. After that issue is addressed,
only DNS will remain.

regards,
Nikos

---

From: Michael StJohns <[email-masked]>
Date: Mon, 17 Mar 2014 10:41:53 -0400

> What about extensions? SRP Data, Client/Server Auth data, Padding?
Sorry - I should have put it like this (which AFAIK reflects the F2F 
discussion):

SNI is the only one of these that needs to be sent upfront - the rest 
can be done (albeit expensively) at later stages of the negotiation.

> wouldn't be exposing 1024 DH all over the place.

I don't actually understand this point.  You're saying because the DH 
negotiation is encrypted under a key negotiated by a previous DH 
negotiation, then 1024 bit DH would be safe?

> protocol you don't choose the smallest security margin you can think

All of this is motherhood I agree with except with "protecting 
everything" because TANSTAAFL - there ain't no such thing as a free 
lunch - everything costs and sometimes provides little benefit.  But 1) 
what problem is this trying to solve?  2) How much cost is involved - on 
the client side and on the server side?  3) How much does this increase 
the attackers work factor?   These are all question I look at before 
deciding to move forward with a solution.

I'm unclear that we've agreed on the problem we're trying to solve (or 
problems), (And encrypt everything is not the problem, its the tool).

Mike

---

From: Michael StJohns <[email-masked]>
Date: Mon, 17 Mar 2014 11:08:55 -0400

> information on the outside, so you can see if that connection needs to

Or the CMT just blocks all access to the device because its a known SNI 
encryption box.    If you get to assign super powers to an entity to 
make your point, then so do I.

> of the goals we need it to.

And unfortunately, I don't think EKRs proposal does it either.

There are a few things you need to do symmetric encryption - a mutual 
key and an agreed upon cipher suite.  EKR proposes retaining the keys 
and suite from a previous connection and using them to encrypt the 
negotiation for the next connection.  To do this, both client and server 
cache the previous keys.   If you have no previous connection, or you or 
the server have timed out the cached keys, EKR has you fall back to 
doing an unencrypted negotiation followed by an encrypted negotiation.  
Unfortunately, as I understand how this works, the SNI needs to be in 
the first negotiation so that the director can steer the packets to the 
appropriate server.

Assuming super powers that let me twiddle with packets in flight - I 
modify the MAC over the negotiation records to cause it to fail 
verification at the server.  Or I intercept the response from the server 
and replace it with an unsigned "sorry, no cached key" error message.  
Either way causing the client to fall back into unencrypted mode.

This gets worse when the virtual server director isn't actually on the 
same server as the actual server, as the director will need copies of 
the keys in the same timely fashion as the servers.  And that makes the 
director a big juicy target.  (Seriously a single box with all the 
session keys for 1000s of sessions with 100s of servers? Let me at it)  
The threat could be partly mitigated by deriving a separate set of keys 
for "next session encryption negotiation", but that would change the 
current key expansion stages a bit.  And still begs the question of how 
keys get from the virtual server to the director so this can be done.

Another approach might be for the client (only) to retain the public key 
of the specific destination server, or a special use public key handed 
to the client by the server as part of another negotiation (and which 
related private key is shared with the director - said key being very 
long lived).  Use that to encrypt the SNI (either RSA encryption, or 
something like ECIES for elliptic curve).     And even use that as the 
encryption over the negotiation.

Mike

---

From: Erik Nygren <[email-masked]>
Date: Mon, 17 Mar 2014 11:26:20 -0400

As someone mentioned in London, the SNI header is layer-7 routing
information (similar to how the IP address is layer-3 routing information
and the TCP port is layer-4 routing info).  As much as we would all
(hopefully?) love to protect it from a privacy perspective, it may turn out
to be hard to do so in today's Internet without making hard trade-offs.
The cases where encrypting SNI has value is where there is a 1:many
association between IP and ServerName (including in cases where the server
with the keys is on a different physical machine and perhaps different
trust domain from the server terminating the TCP connection).  But those
are also the cases hard to implement here.  Today (due to lack of adequate
client adoption of SNI), many servers just use a 1:1 association here.

> I think what we're getting to is that if we have a system where there is
a middle box, then neither of these approaches
> makes a lot of sense for the scale you're talking about?

Right, especially in the case where the middle box is just a load-balancer
or demuxer and doesn't have the keying information.  Take the example of a
virtual hosting cloud provider that has a TCP-terminating load balancer
with public addresses that clients connect to (perhaps tens or hundreds of
IPv4 addresses?) and then has a large pool of servers behind it operated by
different entities with no shared trust (in private or IPv6 address space,
perhaps with each backend server having many hostnames).  In HTTP, the load
balancer can just use the Host header to route traffic to the right place.
With TLS without SNI, an IP address is needed per cert (which doesn't scale
in IPv4 to allow pervasive use of TLS).  With unencrypted SNI, the load
balancer can demux connections to the proper server based on the SNI
header. With encrypted SNI, this only works if there's an additional
round-trip and the SNI header (and server cert and other things we want to
protect) are covered by a key in the load balancer's trust domain (with
that key never being used for anything sensitive).  The end result of the
encrypting at the client-hello level is thus opportunistic, with the
similar effective results as if ipsec with anonymous was used to encrypt
the connection (with TLS with SNI-in-the-clear then being over the ipsec
connection).

There are hundreds of millions of websites out there, all being handled by
a highly heterogeneous mix of cloud providers, single server deployments,
CDNs, embedded devices, and more.  If we want to get pervasive TLS out
there, we need to make sure that it can be deployed in all of these.
Getting adequate TLS SNI adoption in clients is one of the gating factors
for more pervasive use of TLS, and if we break the ability to use TLS SNI
with adequate performance/cost in some of the key deployment scenarios then
it could be a barrier to adoption.

    Erik

On Sun, Mar 16, 2014 at 7:47 PM, Michael StJohns <[email-masked]>wrote:

> between DOS protections and negotiation protections), but I wanted to focus
> on the 100K.
>
> system, how do the end systems communicate with the middle box to pass on
> their key info and keep it up to date - not on a per-box 100K basis, but on
> a 100K times the number of connections per box?
>
> I think what we're getting to is that if we have a system where there is a
> middle box, then neither of these approaches makes a lot of sense for the
> scale you're talking about?
>
> Mike
>
>

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 17 Mar 2014 08:33:10 -0700

On Mon, Mar 17, 2014 at 8:08 AM, Michael StJohns <[email-masked]>wrote:

> encryption box.    If you get to assign super powers to an entity to make
> your point, then so do I.
>
>
>
> There are a few things you need to do symmetric encryption - a mutual key
> and an agreed upon cipher suite.  EKR proposes retaining the keys and suite
> from a previous connection and using them to encrypt the negotiation for
> the next connection.  To do this, both client and server cache the previous
> keys.   If you have no previous connection, or you or the server have timed
> out the cached keys, EKR has you fall back to doing an unencrypted
> negotiation followed by an encrypted negotiation.  Unfortunately, as I
> understand how this works, the SNI needs to be in the first negotiation so
> that the director can steer the packets to the appropriate server.
>

Just for clarity, this is not quite what I was proposing. Rather, I was
proposing that if the cached keys expired, you did an anonymous
DH exchange, so you get protection for the target server against
passive attack but not active attack. I agree that you can mount
an active attack as suggested below, though it cannot be done
totally transparently.

This gets worse when the virtual server director isn't actually on the same
> server as the actual server, as the director will need copies of the keys
> in the same timely fashion as the servers.  And that makes the director a
> big juicy target.  (Seriously a single box with all the session keys for
> 1000s of sessions with 100s of servers? Let me at it)

Note that this situation is a fairly standard configuration for SSL
acceleration
devices in any case. What's different here is primarily that the load
balancer
is not generally required to be trusted.

> of the specific destination server, or a special use public key handed to
> the client by the server as part of another negotiation (and which related
> private key is shared with the director - said key being very long lived).
>  Use that to encrypt the SNI (either RSA encryption, or something like
> ECIES for elliptic curve).     And even use that as the encryption over the
> negotiation.

Without digging too much into the details just yet, it seems to me
that the key element if you want to have protection against active
attack is that the client must be able to directly verify that a given
key is owned by the server in a way that cannot be substituted by
the attacker. The challenge, of course, is that the information
that the server uses to authenticate that key inherently reveals
the server's identity. I see two basic options [0]:

- Have the client acquire the server's key over some untrusted channel
and accept that it can be monitored the first time.

- Have the server provide a large set of keys (like all the ones that
it supports) to the client and then the client can choose one.

Note that in either case, this represents a commitment by the server to
use that key through it's expiry window. i.e., it's hard state rather
than soft state, which people have been so far reluctant to do with
HPKP. Both of these have obvious drawbacks, so it's a
compromise.

-Ekr

[0] I'm assuming we restrict ourselves entirely to the TLS channel.
If we are willing to have data in, for instance, the DNS, there are other
options for disseminating the initial key data.

---

From: Tom Ritter <[email-masked]>
Date: Mon, 17 Mar 2014 20:23:04 -0700

On 17 March 2014 07:41, Michael StJohns <[email-masked]> wrote:
> SNI is the only one of these that needs to be sent upfront - the rest can be
> done (albeit expensively) at later stages of the negotiation.

That's fair, thanks.

> negotiation, then 1024 bit DH would be safe?

Nope, I'm saying if I'm waving a fairy wand and randomly
rearchitecting protocols in the past, TLS _might_ have had the DHE
negotiation occur inside a channel protected by the non-PFS RSA key.
In my alternate world, we're able to upgrade the RSA key (1024, 2048,
4096) but due to annoying client restrictions, not the 1024 DH. And in
the alternate world, the 1024 DH handshake is protected by the 2048
RSA - you can't attack the 1024 without breaking the 2048.  (Like you
can now.)

It's just an example where data that was sent in the clear, instead of
in a secure channel, enabled attacks in an unexpected way a decade or
more later.

> All of this is motherhood I agree with except with "protecting everything"
> because TANSTAAFL - there ain't no such thing as a free lunch - everything
> costs and sometimes provides little benefit.  But 1) what problem is this
> trying to solve?  2) How much cost is involved - on the client side and on
> the server side?  3) How much does this increase the attackers work factor?
> These are all question I look at before deciding to move forward with a
> solution.
>

That's fair.  I imagine not everyone agrees with me when I see the
problem as "The client communicates version information, options, and
preferences outside a channel protected against a passive adversary.
The client is unable to communicate information it deems very
sensitive in a channel protected against an active adversary*."

* I suppose the caveat there would be "in a way performant enough for
anyone to use it" ;)

The arguements I really disagree with are the ones of the form:
 - There's no reason to try and hide the options one supports, because
the User-Agent will be sent at an earlier or later time in plaintext.
 - DNS lookups mean the data is exposed anyway, so who cares about it.

These arguements assume a specific operating environment and model.
While it's true it's common today, there is no guarentee that it will
be true tomorrow, or that someone won't try and tackle those problems
elsewhere.  It's also violating the principal of layering - I
shouldn't care what's happening at a different layer, I should make my
thing independent and secure.

I'm wondering if there is an approach here to hide the SNI against a
passive adversary, but not an active adversary - with the ability to
'bolt-on' strong authentication of 'ephemeral' keys if the stronger
protection is needed...

-tom

---

From: Michael StJohns <[email-masked]>
Date: Mon, 17 Mar 2014 23:33:52 -0400

On 3/17/2014 11:33 AM, Eric Rescorla wrote:
>
>
>
> On Mon, Mar 17, 2014 at 8:08 AM, Michael StJohns 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     There are a few things you need to do symmetric encryption - a
>     mutual key and an agreed upon cipher suite.  EKR proposes
>     retaining the keys and suite from a previous connection and using
>     them to encrypt the negotiation for the next connection.  To do
>     this, both client and server cache the previous keys.   If you
>     have no previous connection, or you or the server have timed out
>     the cached keys, EKR has you fall back to doing an unencrypted
>     negotiation followed by an encrypted negotiation.  Unfortunately,
>     as I understand how this works, the SNI needs to be in the first
>     negotiation so that the director can steer the packets to the
>     appropriate server.
>
>

Right - what I said - you do an unencrypted negotiation by offering an 
ANON suite or suites (probably the latter to prevent DH from becoming 
indispensible) in a clear text ClientHello.  You then re-use the key 
from that negotiation to encrypt the re-negotiation handshake exchanges.

>
>
>     This gets worse when the virtual server director isn't actually on
>     the same server as the actual server, as the director will need
>     copies of the keys in the same timely fashion as the servers.  And
>     that makes the director a big juicy target.  (Seriously a single
>     box with all the session keys for 1000s of sessions with 100s of
>     servers? Let me at it)
>
>

Yup.

>
>
>      The threat could be partly mitigated by deriving a separate set
>     of keys for "next session encryption negotiation", but that would
>     change the current key expansion stages a bit.  And still begs the
>     question of how keys get from the virtual server to the director
>     so this can be done.
>
>     Another approach might be for the client (only) to retain the
>     public key of the specific destination server, or a special use
>     public key handed to the client by the server as part of another
>     negotiation (and which related private key is shared with the
>     director - said key being very long lived).  Use that to encrypt
>     the SNI (either RSA encryption, or something like ECIES for
>     elliptic curve).   And even use that as the encryption over the
>     negotiation.
>
>
three?

> it supports) to the client and then the client can choose one.
Do this as a public key operation instead of a symmetric key op, and 
have the server provide a public key specific to the "encrypt the 
handshake" protection during one of the prior connections.  That gets 
cached by the client.

I mention this for completeness.  It has the benefit of not requiring 
the server to cache anything, but the potential downside of a DOS attack 
based on the cost to derive a key.  But that's no worse than an ANON 
negotiation I think.  If you cache the client public key and/or the 
derived shared secret you mostly eliminate that issue (but loses you 
some of the benefit of the approach).