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

Dave Garrett <> Tue, 22 September 2015 17:57 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 93A3A1A9218 for <>; Tue, 22 Sep 2015 10:57:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nI6nuQyLegfH for <>; Tue, 22 Sep 2015 10:57:12 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 084641A9173 for <>; Tue, 22 Sep 2015 10:57:09 -0700 (PDT)
Received: by ykdg206 with SMTP id g206so17433067ykd.1 for <>; Tue, 22 Sep 2015 10:57:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=9pH0+3AK871Bf/kqYSIPLQ5qEMUEmlJ+MQVG3MS33Jk=; b=GxixNoEM0hwvyO9W6B+TT32VQB06+TAwTZXBDbzGnaPBF+y79+3vHSuUpq8h5+hvHp bHP/USQRfiBlXdDFQB/LqEUA9JxHaSuvIIkpnUe+l1esVl8kj3cN1VHxrSAfx1X+wgPn 5oMRHEViY5aD+0Rpi7GCAG185adRYmqTPTBWwU5dJXXGy8wm/MlqL0Xn1Fj+867ujlls xXwMql7UUPchEVtRx6c4Js1zoBD0FLWbb0XaHrH0akfu69lE6LBaaFupNPtmFDXGHb6b BZcfWkNFJ7x2Mbq/n+DoHdWZ7MjxtgA9nS1ND/bJwTZ5SyzirGgwpHbi1CzEFErXd+OD YcKA==
X-Received: by with SMTP id n187mr22658456yka.54.1442944628385; Tue, 22 Sep 2015 10:57:08 -0700 (PDT)
Received: from dave-laptop.localnet ( []) by with ESMTPSA id f126sm1557076ywe.47.2015. (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 22 Sep 2015 10:57:07 -0700 (PDT)
From: Dave Garrett <>
Date: Tue, 22 Sep 2015 13:57:06 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References: <> <> <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <>
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: Tue, 22 Sep 2015 17:57:17 -0000

I've been effectively convinced that encrypted SNI can only provide mild protection in some specific instances, and usually only provides a false sense of security. That said, if someone does want to design a system, I can think of a relatively easy route forward here. The TLS 1.3 spec will be introducing Server Configuration Extensions (different from Hello extensions). Encrypted SNI could be implemented by creating a config extension to provide a second semi-static key to be used for SNI encryption. This would require server configurations be distributed through some out-of-band route, but this will probably already be desired and is not really avoidable if you want to encrypt something in the first-flight, like SNI. Without this, at least repeat connections could have SNI encrypted. This ESNI key would be shared across virtual servers and be issued by the host. The same server_name hello extension would be used, but it'd just be encrypted for hosts that support it.

The even simpler route is to just put the SNI extension in EncryptedExtensions when possible, but that requires sharing one 0RTT key across all virtual servers on the host. There's probably plenty of situations where this is fine, but I think it'd be better to just generalize things to have a second key and avoid problems here, at this point.