Re: [TLS] DNS-based Encrypted SNI

Brian Sniffen <> Fri, 06 July 2018 21:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E3CC713107B for <>; Fri, 6 Jul 2018 14:41:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 2.29
X-Spam-Level: **
X-Spam-Status: No, score=2.29 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_ROLEX=5, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bOU2YnBV7hVT for <>; Fri, 6 Jul 2018 14:41:37 -0700 (PDT)
Received: from ( [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 86A051310AF for <>; Fri, 6 Jul 2018 14:41:36 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id w66Lfaer006489; Fri, 6 Jul 2018 22:41:36 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : content-transfer-encoding; s=jan2016.eng; bh=29o8M5M9Ef4NhJx1I9+ck/XwuCDOcjrV6dbaNMRohBY=; b=bl7kyQSG0EunVmcg9H6074LeiAn0MAwNbwoH5AIPj1geOxV0pazQCO/G76R6XWERY965 bqzsOzdUnHubC/FbcfI8JLHzgq6oaQMt3VPr5Ym1cmEOSz8Nq74/mAj2WCR/opUy49ui kU7D9yD66+ytq5cuPmeL5IhHgeeXVypzOkL7KQcAitjL/1bNrawgFKM4rZ0j2PhVU/w9 687LwPBTuw3DV285wo8+707XtpJcYR5E3dVEIs4WBYh1rwM7gnlO0KlQk+Eqd0P1s59o mNaM3iKza4LwJLC0vE0JyIzo+6eDybvzVonStR4brcOAZA8cAeQs3m23/Ljfd7JRx11E Pw==
Received: from prod-mail-ppoint2 ( []) by with ESMTP id 2k269j9ekf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 06 Jul 2018 22:41:36 +0100
Received: from pps.filterd ( []) by ( with SMTP id w66LYqgS006220; Fri, 6 Jul 2018 17:41:34 -0400
Received: from ([]) by with ESMTP id 2jx56vhwkt-1; Fri, 06 Jul 2018 17:41:34 -0400
Received: from (unknown []) by (Postfix) with ESMTP id A8D231FC0E; Fri, 6 Jul 2018 21:41:34 +0000 (GMT)
From: Brian Sniffen <>
To: Eric Rescorla <>
Cc: "<>" <>
In-Reply-To: <>
References: <> <> <>
Date: Fri, 06 Jul 2018 17:41:34 -0400
Message-ID: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-06_06:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=2 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807060241
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-06_06:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=2 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807060242
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: Fri, 06 Jul 2018 21:41:47 -0000

Eric Rescorla <> writes:

> On Tue, Jul 3, 2018 at 7:26 AM, Sniffen, Brian <> wrote:
>> Looks neat.
>> 1) TFO DOS vector: is the idea servers will disable TFO under strain but
>> not be able to disable ESNI?
> I hadn't thought about it, but that seems right. I'm not really seeing why
> this is a DOS vector? At present, if you're able to pass a routability
> test, you can force a server to do a DH exchange and a signature, so
> forcing them to do ESNI decryption doesn't seem like it's that much of an
> amplification.

This is the same worry I had talking about ESNI the first time: if
experiencing a lot of load, a server operator might like to route the
load-generating customers / apps / users to a different set of servers.
To do that, he needs to know which customers / apps / users are inviting
the load.  Is this a flash crowd to or
Having to do crypto to determine that makes it *much* more expensive.
It rules out a bunch of ways of doing it on a separate device that
doesn't have the decryption key.

I guess you could put the ESNI key on scrubbing devices (Cisco, Arbor,
Prolexic) and not give them the real TLS keys?  That takes away the
routability test---they just test a sample of what's on the wire, but
that's probably okay.

>> 2) “clients might opt to attempt captive portal detection to see if they
>> are in the presence of a MITM proxy, and if so disable ESNI.”
>> If I’m operating a great firewall, I can use this to discover dissidents,
>> right?  Either they send me dangerous SNI values or they are configured to
>> not disable ESNI, and taking the fifth is fatal. To protect them, I think
>> nobody can have this mode.
> This doesn't sound right to me. The idea here is that you only disable ESNI
> if the attacker is able to generate a valid TLS connection to a
> *non-default* root, which means that they are MITM-capable, which nation
> state firewall operators typically are not. And of course if they are, then
> you have real problems. Can you walk me through the flow you have in mind.

My nation-state operator adversaries typically are MITM-capable.  Hunh.
And yes, I have real problems!  Lucky me.

But to generalize: even if it can't be done at the GFWoC, it's still
dangerous if done a cafe at a time.

>> 3) How many bits does this offer? Hiding in a set of a million uniform
>> hosts is 20 bits,
> Well, I would say it's got an anonymity set of 2^{20}. It's not 20 bits
> strong in the sense that the attacker can do a computation of cost 2^{20}.n
> and the nonuniformity will accrue to the adversary’s benefit. Active
>> probing will unmask visitors to dissident sites.
> I don't really follow this. Can you explain?

I think it's at most 20 bits strong: the attacker can do a computation
of cost 2^{20}, and crack the anonymity.  It involves 2^{20}
cafe-at-a-time compromises, or 2^{20} operations involving rubber hoses.

But I think it's a *lot* weaker than 2^{20}: the needles of the
adversary's search are not uniformly distributed.  So he can block the
most popular site for a day.  That doesn't take off 1 bit; that takes
off the vast majority of the clients.  If sites are on a power-law
distribution, it gets down to where the remaining 2^5 are rubber-hosable
in just a few experiments.


> -Ekr
> I worry that this tool is so weak against a GFW-style adversary for the
>> purpose of allowing dissident access to restricted web sites that it will
>> be dangerous if released. But maybe I misunderstand the purpose. If this is
>> just to keep Western ISPs from monkeying with traffic, sure, ship it.
>> Labelling the encryption with its strength as applied, or showing CDNs and
>> ISPs how to work out some bounds, seems one way to help users understand
>> whether this can help them or put them more at risk.
>> --
>> Brian Sniffen

Brian Sniffen
Akamai Technologies