Re: [TLS] About encrypting SNI

[Martin Thomson <[e-mail]>]

Rich,

Did you consider the solution proposed by dkg at the meeting?  That
is, embed routing information in the server_key_label [1].  That means
that you can identify flows as precisely as you need prior to
decrypting.  No need then for 15m IP addresses, certainly.

--Martin

[1] http://tools.ietf.org/html/draft-rescorla-tls13-new-flows-01#section-6.4.3

On 7 April 2014 07:29, Salz, Rich <[e-mail]> wrote:
> I have concerns some about SNI encryption.
>
> First, I think it addresses a problem that is actually not that important for most. There are comparatively few sites on the web that have multiple properties served from a single host (or cluster). Certainly the biggest sites that received the most publicity for being under attack by the NSA -- Microsoft, Google, Yahoo, etc. -- are really a few to smallish number of services. And those companies have the wherewithal to deploy separate identities and IP addresses for their properties.
>
> Second, it potentially disadvantages a portion of the net: large CDN's and their customers. My employer, for example, serves thousands of sites on its TLS network, and encrypting SNI requires us to either have a single long-lived keypair for all customers, or require an extra RTT for clients to fetch an EDH key, perhaps still shared, but hopefully more secure. The latter is particularly off-putting since customers paying for a "faster, better" end-user experience are now at a disadvantage. Some in this community might not deploy TLS 1.3 to avoid the "retry penalty." This would be a shame.
>
> Third, we have not heard from the real potential community of consumers of this. I posit that they are mid-size sites with a "handful" of hosted properties. They are currently adequately served by virtual IP's, and even more so in the future by IPv6. And in terms of adversaries, does it matter which property within peacefire, for example, a user is contacting?  A site under surveillance by a national-scale adversary will have *everything* scooped up anyway.
>
> Let me put some numbers on the previous points. We deliver content for around 10K domains, each with its own RSA keypair, out of 1500 locations. Without SNI, that means we need 15Million IP addresses, while being able to use SNI we only need one per location (region in our terminology). With SNI encryption we either need to share keys (bad for security, and perhaps not compliant with some regulations) or fragment IPs (bad for the web long-term). And that's just us.  Add in all the CDNs, hosting companies, cloud providers... it's big.  Do we know what people like AWS, Rackspace, IBM Cloud, etc., think about this?
>
> Fourth, it potentially "unlevels" the playing field. Organizations that have both a browser and servers of interest could, trivially, arrange to push out keys on a regular basis. I am not suggesting that anyone is planning on doing this, but I fear the temptation to do so in the name of "improving the user experience" will prove too great. In darker moments, I extrapolate the " browser list of  CA's" story and imagine a future where Chrome talking to Google will be faster than IE talking to Bing, and Firefox will end up selling slots in its EDH store (sic) to attract revenue.
>
> Fifth, it introduces unknown security and trust implications in browsers. It took years to make "certificate stores" actually secure. And we are potentially opening up a new avenue of active attacks over the network while increasing the expectation that things are more secure. We are also increasing the client-side attack surface.
>
> Sixth, it adds an extra burden to servers. I think it also improves potential DoS attacks, since they could start at the first PDU exchange.
>
> Seventh, it ignores some of our own history. When HTTP/1.1 mandated the Host header, the virtual hosting industry was created. Until virtual IP's were well-known and SNI was widely adopted (I'm being charitable here), adoption of TLS among hosting providers had significant drag. If SNI is routing, then routing is plaintext and we are now going hide it without understanding the trade-offs.
>
> Finally, it is a lot of mechanism.  As ekr said in London, "you have to do all this if you want to protect the SNI." It's not worth it.
>
> I think we're going too far, and we should come down on the side of simplicity, not for its own sake, but for security's sake.
>
>         /r$
> --
> Principal Security Engineer
> Akamai Technology
> Cambridge, MA
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls