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

[Erik Nygren <[e-mail]>]

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 <[e-mail]>wrote:

> 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.
>>
>> 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).
>>
>
> 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
>
>