Re: [TLS] About encrypting SNI
Daniel Kahn Gillmor <dkg@fifthhorseman.net> Mon, 14 April 2014 19:56 UTC
Return-Path: <dkg@fifthhorseman.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF43A1A0726 for <tls@ietfa.amsl.com>; Mon, 14 Apr 2014 12:56:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Level:
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qigHEGLRHKnA for <tls@ietfa.amsl.com>; Mon, 14 Apr 2014 12:56:26 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 326BF1A0654 for <tls@ietf.org>; Mon, 14 Apr 2014 12:56:24 -0700 (PDT)
Received: from [10.70.10.85] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 4F2EBF984; Mon, 14 Apr 2014 15:56:19 -0400 (EDT)
Message-ID: <534C3D5A.3020406@fifthhorseman.net>
Date: Mon, 14 Apr 2014 15:56:10 -0400
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.3.0
MIME-Version: 1.0
To: "Salz, Rich" <rsalz@akamai.com>, "TLS@ietf.org (tls@ietf.org)" <tls@ietf.org>
References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com>
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com>
X-Enigmail-Version: 1.6+git0.20140323
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="wiauwvs430RSK51I5bjCvi5CoBM44CHCv"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/iTLr1AgB4eizi1mJggBZ6gMVGzQ
Subject: Re: [TLS] About encrypting SNI
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Apr 2014 19:56:29 -0000
Hi Rich, all-- I want to speak up in favor of encrypting SNI (and the rest of the TLS handshake) if at all possible. It would be a shame if TLS did not support sites who wanted to be private except to their clients. If we drop plans to encrypt SNI, we make the tasks of would-be censors and surveillance operators much easier. On 04/07/2014 10:29 AM, Salz, Rich wrote: > 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). Measured by traffic, you may be correct. But if you measure by number of web sites, the opposite is likely to be true. Far more small sites (each with low amounts of traffic) are aggregated on shared hosting providers that re-use IP addresses between sites. These are sites that we will want to protect from passive monitoring. If the default is to protect SNI information from passive eavesdropping, websites which share IP addresses with other sites will be able to remain "dark". (yes, the dns-privacy project will also have to come up with a reasonable fix to that leak). If there is no expectation that servers should be able to handle encrypted SNI, then clients will be unable to hide the identity of the web site they visit from an eavesdropper. For web sites whose names themselves are cause for concern to censors or surveillance operators, and who may evade network address based censorship or monitoring by changing IP addresses fluidly, encrypted SNI is an important mechanism. > Second, it potentially disadvantages a portion of the net: large CDN's and their customers. I appreciate that large CDNs and their customers face special operational concerns. They already do, whether we encrypt SNI or not. Large CDNs are also uniquely positioned to be able to sort out technical solutions to the challenges posed by encrypted SNI to their business model. On the other hand, If we don't support a mechanism that permits encrypted SNI, then instead we instead severely disadvantage smaller sites that are more vulnerable to censorship and surveillance, and those smaller sites have little recourse other than requiring their guests to use Tor, which comes with its own set of concerns. This is a bad tradeoff. > 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. The discussion of possible handshake flows suggests that the extra RTT does not need to be in every handshake; several proposals for "semi-static" DHE keys have been put forward already, and second-connections need not have the extra RTT. Depending on how we define the mechanism, the initial SNI-protecting DHE key could even be per-IP address, rather than per-domain, which would allow further reductions in RTT for sites hosted on large farms with a few public-facing IP addresses. > 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. A major goal is to make traffic to a domain that would be censored as indistinguishable as possible from traffic that would not be censored. If the "solution" is to give each site its own IP address, then we've lost that goal: a censor simply blocks based on IP address. > 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? You're describing this as though encrypting SNI would mean no more SNI, or one IP address needed per web site. This is not the proposal. > 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. ??? If browser vendors want to play these kinds of games, there are already many ways they can play them, up to and including deliberate miscommunication with a competitors' services or software. they're generally not doing that, because it's bad for business. If speed is critical enough to encourage vendors to publish DHE keys for specific IP addresses on a regular basis, they'll want to do this in a standard way that browsers and web site operators could collaborate on. > 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. I'm not convinced that certificate stores are "actually secure" if we look at them from a usability perspective, but i think that's a tangent to the SNI point. I think the "new avenue of active attacks" you describe are attacks that: a) are likely to result in connection failures if we design the protocol well b) require timing-sensitive, active control on the 'net, and c) result in revealing server name indication and other handshake parameters. If we opt to avoid encrypting SNI or other parts of the handshake, then a simple passive attacker gets (c) for free, and doesn't need to bother with their own increased visibility (a) or technical difficulty (b). I don't see how avoiding encrypted SNI is a security win, when seen from this perspective. > 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. I agree, we need to consider this computational burden. Whatever we can do to ensure that DoS amplification is minimal would help legitimate deployments. > 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. SNI is communications metadata. If we've seen anything from the discussions and information leaked over the last year, it's that communications metadata is of deep and abiding interest to global surveillance regimes, including those whose activities the IETF has clearly indicated are worth treating as an attack on the 'net. One of the oft-cited complaints about attempts to secure e-mail in an end-to-end fashion is that the header information is not protected. We should avoid leaving TLS in that same state if we can help it. I'm happy to work with folks who have performance and operational concerns to make sure we can address them with an encrypted handshake. These are design tradeoffs that lend themselves to gradual improvement, whether through caching or preloading or other mechanisms. But if we design a new version of TLS that does not encrypt the handshake properly, we leave critical pieces of metadata exposed on the wire for passive attackers, and there are no clear ways to avoid the leakage for people who care about it. Regards, --dkg
- [TLS] About encrypting SNI Salz, Rich
- Re: [TLS] About encrypting SNI Martin Thomson
- Re: [TLS] About encrypting SNI Salz, Rich
- Re: [TLS] About encrypting SNI Watson Ladd
- Re: [TLS] About encrypting SNI Russ Housley
- Re: [TLS] About encrypting SNI Eric Rescorla
- Re: [TLS] About encrypting SNI Brian Sniffen
- Re: [TLS] About encrypting SNI Alyssa Rowan
- Re: [TLS] About encrypting SNI Nick Mathewson
- Re: [TLS] About encrypting SNI Daniel Kahn Gillmor
- Re: [TLS] About encrypting SNI Sniffen, Brian
- Re: [TLS] About encrypting SNI Yoav Nir
- Re: [TLS] About encrypting SNI Salz, Rich
- Re: [TLS] About encrypting SNI Seth David Schoen
- Re: [TLS] About encrypting SNI Nico Williams
- Re: [TLS] About encrypting SNI Watson Ladd
- Re: [TLS] About encrypting SNI Salz, Rich
- Re: [TLS] About encrypting SNI Yoav Nir
- Re: [TLS] About encrypting SNI Salz, Rich
- Re: [TLS] About encrypting SNI Watson Ladd
- Re: [TLS] About encrypting SNI Salz, Rich
- Re: [TLS] About encrypting SNI Eric Rescorla
- Re: [TLS] About encrypting SNI Alyssa Rowan
- Re: [TLS] About encrypting SNI Salz, Rich
- Re: [TLS] About encrypting SNI Martin Rex
- Re: [TLS] About encrypting SNI Eric Rescorla
- Re: [TLS] About encrypting SNI Eric Rescorla
- Re: [TLS] About encrypting SNI Andy Lutomirski
- Re: [TLS] About encrypting SNI Eric Rescorla
- Re: [TLS] About encrypting SNI Tom Ritter
- Re: [TLS] About encrypting SNI Brian Sniffen
- Re: [TLS] About encrypting SNI Andy Lutomirski
- Re: [TLS] About encrypting SNI Andy Lutomirski
- Re: [TLS] About encrypting SNI Salz, Rich
- Re: [TLS] About encrypting SNI Eric Rescorla
- Re: [TLS] About encrypting SNI Watson Ladd
- Re: [TLS] About encrypting SNI Brian Sniffen
- Re: [TLS] About encrypting SNI Andy Lutomirski
- Re: [TLS] About encrypting SNI Andy Lutomirski
- Re: [TLS] About encrypting SNI Sniffen, Brian
- Re: [TLS] About encrypting SNI Andy Lutomirski
- Re: [TLS] About encrypting SNI Alyssa Rowan
- Re: [TLS] About encrypting SNI Michael D'Errico
- Re: [TLS] About encrypting SNI James Cloos
- Re: [TLS] About encrypting SNI Jacob Appelbaum
- Re: [TLS] About encrypting SNI Andy Lutomirski
- Re: [TLS] About encrypting SNI Erik Nygren
- Re: [TLS] About encrypting SNI Andy Lutomirski
- Re: [TLS] About encrypting SNI Jacob Appelbaum
- [TLS] Forged RST (was: About encrypting SNI) Alyssa Rowan
- Re: [TLS] Forged RST (was: About encrypting SNI) Eric Rescorla
- Re: [TLS] About encrypting SNI Paul Lambert
- Re: [TLS] About encrypting SNI Andy Lutomirski
- Re: [TLS] About encrypting SNI Erik Nygren
- Re: [TLS] About encrypting SNI Andy Lutomirski
- Re: [TLS] Forged RST (was: About encrypting SNI) Yoav Nir
- Re: [TLS] About encrypting SNI Sniffen, Brian
- Re: [TLS] Forged RST (was: About encrypting SNI) Erik Nygren
- Re: [TLS] About encrypting SNI James Cloos
- Re: [TLS] Forged RST Stephen Farrell
- Re: [TLS] About encrypting SNI Andy Lutomirski
- Re: [TLS] Forged RST (was: About encrypting SNI) Nico Williams
- Re: [TLS] About encrypting SNI Erik Nygren
- Re: [TLS] About encrypting SNI Sniffen, Brian
- Re: [TLS] About encrypting SNI Andy Lutomirski
- Re: [TLS] About encrypting SNI Martin Thomson
- Re: [TLS] About encrypting SNI Brian Sniffen
- Re: [TLS] About encrypting SNI Eric Rescorla
- Re: [TLS] About encrypting SNI Sniffen, Brian
- Re: [TLS] About encrypting SNI Erik Nygren
- Re: [TLS] Forged RST (was: About encrypting SNI) Bill Frantz
- Re: [TLS] Forged RST (was: About encrypting SNI) Yoav Nir
- Re: [TLS] Forged RST (was: About encrypting SNI) Bill Frantz
- Re: [TLS] Forged RST (was: About encrypting SNI) Eric Rescorla
- Re: [TLS] Forged RST (was: About encrypting SNI) Watson Ladd
- Re: [TLS] Forged RST (was: About encrypting SNI) Eric Rescorla
- Re: [TLS] About encrypting SNI Marsh Ray
- Re: [TLS] About encrypting SNI Martin Rex
- Re: [TLS] About encrypting SNI David Holmes
- Re: [TLS] About encrypting SNI Brian Sniffen
- Re: [TLS] About encrypting SNI Marsh Ray
- Re: [TLS] About encrypting SNI Marsh Ray
- Re: [TLS] About encrypting SNI Nico Williams
- Re: [TLS] About encrypting SNI Andy Lutomirski
- Re: [TLS] About encrypting SNI Michael D'Errico
- Re: [TLS] About encrypting SNI Watson Ladd
- Re: [TLS] About encrypting SNI Erik Nygren
- Re: [TLS] About encrypting SNI Salz, Rich
- Re: [TLS] About encrypting SNI Daniel Kahn Gillmor
- Re: [TLS] About encrypting SNI Salz, Rich
- Re: [TLS] About encrypting SNI - Traffic Analysis… Michael StJohns
- Re: [TLS] About encrypting SNI - Traffic Analysis… Nico Williams
- Re: [TLS] About encrypting SNI - Traffic Analysis… Stephen Farrell
- Re: [TLS] About encrypting SNI - Traffic Analysis… Martin Rex
- Re: [TLS] About encrypting SNI Nikos Mavrogiannopoulos
- Re: [TLS] About encrypting SNI Salz, Rich
- Re: [TLS] About encrypting SNI Stephen Farrell
- Re: [TLS] About encrypting SNI Andy Lutomirski
- Re: [TLS] About encrypting SNI - Traffic Analysis… Martin Thomson
- Re: [TLS] About encrypting SNI - Traffic Analysis… Tom Ritter
- Re: [TLS] About encrypting SNI Brian Sniffen
- Re: [TLS] About encrypting SNI Fabrice
- Re: [TLS] About encrypting SNI Jacob Appelbaum
- Re: [TLS] About encrypting SNI Paul Lambert
- Re: [TLS] About encrypting SNI Yoav Nir
- Re: [TLS] About encrypting SNI Daniel Kahn Gillmor
- Re: [TLS] About encrypting SNI Tim Bray
- Re: [TLS] About encrypting SNI Jacob Appelbaum
- Re: [TLS] About encrypting SNI Paul Hoffman
- Re: [TLS] About encrypting SNI Viktor Dukhovni
- Re: [TLS] About encrypting SNI Brian Sniffen
- Re: [TLS] About encrypting SNI Yoav Nir