Re: [TLS] About encrypting SNI

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Tue, 20 May 2014 20:18 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 9CF5E1A0743 for <tls@ietfa.amsl.com>; Tue, 20 May 2014 13:18:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 Js90a-Hnst_c for <tls@ietfa.amsl.com>; Tue, 20 May 2014 13:18:30 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id DD8B11A072D for <tls@ietf.org>; Tue, 20 May 2014 13:18:29 -0700 (PDT)
Received: from [10.70.10.78] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id A8D24F984 for <tls@ietf.org>; Tue, 20 May 2014 16:18:26 -0400 (EDT)
Message-ID: <537BB889.3040000@fifthhorseman.net>
Date: Tue, 20 May 2014 16:18:17 -0400
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: IETF TLS <tls@ietf.org>
References: <0B76075A-D9F1-4780-8834-7FF0A1C82999@vigilsec.com> <20140425013239.7FE5E1ACE1@ld9781.wdf.sap.corp> <CAFggDF3u1R+540x6SM3Rt5u+GNQ44ZKozCoTSU1k+XMPU9V-tQ@mail.gmail.com> <C81C96A7-0878-4C84-AB8C-CF0BF11841F2@gmail.com>
In-Reply-To: <C81C96A7-0878-4C84-AB8C-CF0BF11841F2@gmail.com>
X-Enigmail-Version: 1.6+git0.20140323
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="fVS4SH1qs9VeKcf1okCru6wsrn6dAAbAS"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/M-EcSFkivuWe4eDbEhmdE6e-9Ro
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: Tue, 20 May 2014 20:18:31 -0000

On 05/20/2014 04:02 PM, Yoav Nir wrote:
> The requirement for encrypted SNI is very simple. I want to browse certain web sites such that if people knew I was browsing them it might get me in trouble. We all like the example of a gay teenager in Uganda, but it could just as well be an American browsing a website advocating Shari’a law for all western countries landing in a no-flight list.
> 
> Encrypting SNI would help if the “suspicious” web site is hosted by a hosting service, and there are multiple innocuous sites on the same IP address, and the traffic from the innocuous sites dominates the traffic to the server, and traffic for this site is not distinguishable by other means such as traffic analysis.  That’s a lot of ‘if’s up there, and if any of them fails, the adversary will know that I browsed the suspicious site. AFAIK Tor provides a far more robust protection of this kind of activity.

I agree that it is a lot of 'if's, and you didn't even mention DNS
privacy, or running a non-compromised web browser, or client operating
system security, or whether the "risky" services are running on
untrustworthy cloud infrastructure, or if they log user traffic via
popular analytics services which themselves could be compromised, or if
the user isn't clearing their browsing history, etc.

I'm sure we can come up with many more problems that could give away the
association between the user and the web site unrelated to either Tor or
TLS.

But the fact that other problems and constraints exist is a terrible
reason to avoid fixing the constrained problems we *can* fix in the
protocol we are responsible for.

	--dkg