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