Re: [TLS] Encrypted SNI (was: Privacy considerations - identity hiding from eavesdropping in (D)TLS)

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Mon, 21 September 2015 15:38 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 3B06D1B332E for <tls@ietfa.amsl.com>; Mon, 21 Sep 2015 08:38:54 -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 Y6Z-VkicA0aE for <tls@ietfa.amsl.com>; Mon, 21 Sep 2015 08:38:52 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id A8D361B3332 for <tls@ietf.org>; Mon, 21 Sep 2015 08:38:50 -0700 (PDT)
Received: from fifthhorseman.net (unknown [167.220.103.147]) by che.mayfirst.org (Postfix) with ESMTPSA id ED3DFF986; Mon, 21 Sep 2015 11:38:48 -0400 (EDT)
Received: by fifthhorseman.net (Postfix, from userid 1000) id 1CFB7204B2; Mon, 21 Sep 2015 11:32:50 -0400 (EDT)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: Viktor Dukhovni <ietf-dane@dukhovni.org>, tls@ietf.org
In-Reply-To: <20150828162251.GM9021@mournblade.imrryr.org>
References: <CAL6x8mchyh2Qpqcd5Rv-rXgZ+1_CAbV7vkib+-yU4DEDFx82Yg@mail.gmail.com> <CAL6x8mfDjYAhOwvBY-tFO-407E9U+SaknJnuh_dCEEUbWJZZWw@mail.gmail.com> <20150828144932.GH9021@mournblade.imrryr.org> <201508281213.03823.davemgarrett@gmail.com> <20150828162251.GM9021@mournblade.imrryr.org>
User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu)
Date: Mon, 21 Sep 2015 08:32:50 -0700
Message-ID: <871tdr23fh.fsf@alice.fifthhorseman.net>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/oRc1c9kVHhOiS7OEPVrQmsMzUHo>
Subject: Re: [TLS] Encrypted SNI (was: Privacy considerations - identity hiding from eavesdropping in (D)TLS)
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: <https://mailarchive.ietf.org/arch/browse/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, 21 Sep 2015 15:38:54 -0000

On Fri 2015-08-28 09:22:52 -0700, Viktor Dukhovni <ietf-dane@dukhovni.org>; wrote:
> So the client would now need to cache some session data by transport
> address, and other data by name and port.  That's rather complex.

This is already done by HTTP/2 clients, since they can access multiple
servers at the same address:port combination.

> And how often will the same client visit multiple servers at the
> same transport address?

*.github.io, *.blogspot.com, massive CDNs, etc.  It's a common pattern.

> I don't really see this as viable or worth the effort.

I disagree -- the metadata leaked to a passive attacker by mandatory SNI
is a valuable signal.  It is worth trying to protect it.

> I don't think SNI hiding is viable without encryption at the
> transport or network layers.

any encrypted SNI is effectively acting as a shim for transport
encryption, yes.  Then again, TLS is itself "transport layer security",
so we should try to provide it at least as an option.

> And there's still a metadata leak via DNS which may prove difficult to
> address.

The DNS community is working to address the DNS leak in DPRIVE.  The TLS
community should be working to fix its own part of the metadata leak.

          --dkg