Re: [TLS] Encrypted SNI

Viktor Dukhovni <> Sat, 05 December 2015 19:31 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 729471A8A89 for <>; Sat, 5 Dec 2015 11:31:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ORGrftmneqWE for <>; Sat, 5 Dec 2015 11:31:01 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 313081A8A8A for <>; Sat, 5 Dec 2015 11:31:01 -0800 (PST)
Received: by (Postfix, from userid 1034) id 0DE34284E32; Sat, 5 Dec 2015 19:31:00 +0000 (UTC)
Date: Sat, 05 Dec 2015 19:31:00 +0000
From: Viktor Dukhovni <>
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <>
Subject: Re: [TLS] Encrypted SNI
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: Sat, 05 Dec 2015 19:31:02 -0000

On Sat, Dec 05, 2015 at 02:15:07PM -0500, Watson Ladd wrote:

> I've got another question: how does the client know that the gateway
> is supposed to be the gateway? As it stands it seems an attacker can
> MITM the Gateway, and recover all SNIs.

That's a whole lot different than passively reading all the SNIs,
if not this or similar, then we're sending the SNI in the clear...

That said, ekr's post includes:

    Important note: this whole discussion punts the question of how
    a client knows that it can do any of this stuff. My assumption
    here is that the client learns it from the Hidden server in some
    unprotected connection or via some side channel (e.g., DNS).

DNS seems to make sense, because in any case the client will already
be asking for the IP address of the same said server via DNS.  It
may as well ask for the 0-RTT key.  If DNS is in the clear for the
IP address, then encrypting SNI is often (absent TOR and the like)
pointless, if DNS is protected then the key lookup is also protected.