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

Daniel Kahn Gillmor <> Mon, 21 September 2015 15:38 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3B06D1B332E for <>; Mon, 21 Sep 2015 08:38:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Y6Z-VkicA0aE for <>; Mon, 21 Sep 2015 08:38:52 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A8D361B3332 for <>; Mon, 21 Sep 2015 08:38:50 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTPSA id ED3DFF986; Mon, 21 Sep 2015 11:38:48 -0400 (EDT)
Received: by (Postfix, from userid 1000) id 1CFB7204B2; Mon, 21 Sep 2015 11:32:50 -0400 (EDT)
From: Daniel Kahn Gillmor <>
To: Viktor Dukhovni <>,
In-Reply-To: <>
References: <> <> <> <> <>
User-Agent: Notmuch/0.20.2 ( Emacs/24.5.1 (x86_64-pc-linux-gnu)
Date: Mon, 21 Sep 2015 08:32:50 -0700
Message-ID: <>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <>
Subject: Re: [TLS] Encrypted SNI (was: Privacy considerations - identity hiding from eavesdropping in (D)TLS)
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 21 Sep 2015 15:38:54 -0000

On Fri 2015-08-28 09:22:52 -0700, Viktor Dukhovni <> 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?

*, *, 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.