Re: [TLS] DNS-based Encrypted SNI

Eric Rescorla <> Wed, 04 July 2018 00:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7A420130E86 for <>; Tue, 3 Jul 2018 17:47:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2CoRow64N4VG for <>; Tue, 3 Jul 2018 17:47:12 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 61CD5130E77 for <>; Tue, 3 Jul 2018 17:47:12 -0700 (PDT)
Received: by with SMTP id t18-v6so1349450ywg.2 for <>; Tue, 03 Jul 2018 17:47:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=346/4ifdu+Sg3YrJkbi4CD2SLFkZwpaWeMfZajjp/PA=; b=kgYjfKMdjVyzV9I8INtjISNB31j7qlfrBg5vTiblju3BkPHufWQY/AX3+tlMS3yupq aIzc4ocNc5BMzLjmHVqDmNwSOaabFs3Qv4V4cpdQSFC0GX8SSnpNjqRW2wHpCKXIf7iR f2/yphZ9eYHE4QywPoPGSvNYQ0FVp+voRm7ebtyaKfqfK7+b9glkCQxt5gRe5twfHikG RBU79YCgi9pD2Pt5U89izBmDDzljjFjlEZeKEHOELp0NNghMsgaC3j3jntConz2IOtWq J/GxyuEKv1wBHzFma/EkN+IwbxeW8oAMUM0EeDrPYwepL+p7t4MDwz91/smuQP8PD5Xp XMAw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=346/4ifdu+Sg3YrJkbi4CD2SLFkZwpaWeMfZajjp/PA=; b=L71nvgz6ocw2cBy2laGuO6NiNXjUsuhEPefl6CHmWm6sAn6oFzAoFYsxGkHZX2sXLE xfHS3vH/8R26zaER4y2IGtSZYYDHxJe811EMu7y9pAWsrGcpEnq4QlJTO3e06j9DR1kK maFpFpeucGvMXgAiA4S4RKiIAjwHgqWKK0mb6/TwQYogM5yQbgOCexpRFCsYUzqjv4XZ 2G4JJtwA04dPurzgkmDU4MHKGs07b1HzGtWAPtuvsQcPDlNDahj3qEXhy/cPoMVQVho/ NQXZJcngvEx3sRb3rr80c9nyi44pugOoMgaAjgrnI7WNans7JlydcgnbTd78XOzsOl0q oSBg==
X-Gm-Message-State: APt69E1ICTRgZQGw7R/pkefjoQw1hJXvx1cfaQJu7nKAI/BZqBOTP5Ik cFQW7PzIodAWqaKVaWLDKOFzWm8EVtY6bgty5i0FQw==
X-Google-Smtp-Source: AAOMgpckCXr7UK1wodfw99lai/hJ137J+l1E+xVhtNThP1us0cdFZiPmDMJe22V5g1Ie0glXdjc9ENdBPTEpqQsch9I=
X-Received: by 2002:a81:b642:: with SMTP id h2-v6mr10426063ywk.102.1530665231546; Tue, 03 Jul 2018 17:47:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a81:6b83:0:0:0:0:0 with HTTP; Tue, 3 Jul 2018 17:46:30 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Eric Rescorla <>
Date: Tue, 03 Jul 2018 17:46:30 -0700
Message-ID: <>
To: "Sniffen, Brian" <>
Cc: "<>" <>
Content-Type: multipart/alternative; boundary="0000000000006591ed057021c5c7"
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 00:47:15 -0000

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

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

> 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 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