Re: [TLS] DNS-based Encrypted SNI

Ilari Liusvaara <> Wed, 04 July 2018 04:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0C5C1130E9D for <>; Tue, 3 Jul 2018 21:50:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EL-_py_j9dbO for <>; Tue, 3 Jul 2018 21:50:17 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C7324130E3E for <>; Tue, 3 Jul 2018 21:50:16 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5F57D21C3F; Wed, 4 Jul 2018 07:50:14 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([IPv6:::ffff:]) by localhost ( [::ffff:]) (amavisd-new, port 10024) with ESMTP id P8X9MlygRnxj; Wed, 4 Jul 2018 07:50:13 +0300 (EEST)
Received: from LK-Perkele-VII ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id C9BFC79; Wed, 4 Jul 2018 07:50:10 +0300 (EEST)
Date: Wed, 04 Jul 2018 07:48:44 +0300
From: Ilari Liusvaara <>
To: Eric Rescorla <>
Cc: "<>" <>
Message-ID: <20180704044844.GB10665@LK-Perkele-VII>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.10.0 (2018-05-17)
Archived-At: <>
Subject: Re: [TLS] DNS-based Encrypted SNI
X-Mailman-Version: 2.1.26
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: Wed, 04 Jul 2018 04:50:21 -0000

On Mon, Jul 02, 2018 at 04:39:14PM -0700, Eric Rescorla wrote:
> I just submitted:
> This draft describes a DNS-based approach to doing encrypted SNI.
> Previously, we had thought this wouldn't work because only sites that
> were particularly vulnerable would do it, and so the use of ESNI marks
> you out. The idea behind this draft is that there are a lot of sites
> which are hosted by -- and whose DNS is run by -- a large provider,
> and that provider can shift many if not all of its sites to ESNI at
> once, thus removing the "standing out" issue and making a DNS-based
> approach practical.

The recent Russia versus Telegram episode is kinda worrisome in this
regard. Basically, it looked like the actions that created massive
collaterial damage got at least two very large cloud provoders to
disable one technique of hiding the name of the target server.

> I am working on an implementation for NSS/Firefox and I know some
> others are working on their own implementations, so hopefully we can
> do some interop in Montreal.
> This is at a pretty early stage, so comments, questions, defect
> reports welcome.

One thing I noticed: First there is this in evaluation:

7.2.4.  Do not stick out

   By sending SNI and ESNI values (with illegitimate digests), or by
   sending legitimate ESNI values for and "fake" SNI values, clients do
   not display clear signals of ESNI intent to passive eavesdroppers.

Is that suggesting to send fake ESNI values? If so, there is this in
endpoint behavior:

5.2.  Client-Facing Server Behavior

   o  If the EncryptedSNI.record_digest value does not match the
      cryptographic hash of any known ENSIKeys structure, it MUST abort
      the connection with an "illegal_parameter" alert.  This is
      necessary to prevent downgrade attacks.

So sending out fake ESNI values seems unsafe. My reading of that is
that if server supports ESNI, but is not configured, then it MUST
terminate (illegal_parameter) any handshake where ESNI extension
was offered in. But that behaviour would cause any split mode
handshakes to fail if backend supports ESNI.