Re: [TLS] Proposals to address ESNI issues

"Christopher Wood" <> Tue, 05 November 2019 20:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 42F4E120B73 for <>; Tue, 5 Nov 2019 12:35:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=AF6c5PcG; dkim=pass (2048-bit key) header.b=cD+5GV9U
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id S5GIautHRKOZ for <>; Tue, 5 Nov 2019 12:35:23 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6BBF7120B87 for <>; Tue, 5 Nov 2019 12:35:21 -0800 (PST)
Received: from compute6.internal (compute6.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 7F04D2206E for <>; Tue, 5 Nov 2019 15:35:20 -0500 (EST)
Received: from imap4 ([]) by compute6.internal (MEProxy); Tue, 05 Nov 2019 15:35:20 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm2; bh=sRkkE ZG1i1xzf9iChEcGU24YzeZS+ptlPBBlHkDCjV0=; b=AF6c5PcGaqe9CI9pKKoMw I6o1WMwVuqUx9Ana1w0ngrx4lO1wd6PHOxbC2wTMT8fGTBmZX6cHc58U/9p7UzTl o5Zm+NC2Xh+ivc3yrmCDtGBAX8XQ7kzWN7v1tI1LkAIHtlYRe/EqGd/4uzt2FMEv ls5oYBtDxvgXAp1QHrqt9KUrH3Y3jH3oJu1A+rDMGHo0ugBXv610KjndH8isHLUE TRrUlHpLge2dn8UQMlH0IwX+kPg/oddFQv2izr75pXQrvsCSJrrTXoOJWfOiw5YH RdQAedQuCCkdr1M6hvEZDiQCinnZlZRxSudlOLswbL6Rr/1M35qM5EArUjgptDcP w==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=sRkkEZG1i1xzf9iChEcGU24YzeZS+ptlPBBlHkDCj V0=; b=cD+5GV9URV/bgtih8XCZLPgnyWEZZXq7b4LkE/0gO9Vm8TiNlntKlr9Ki ytEnnRQHfYv30M0ahby3hmC4cts6Vqt5p08hDCo+CpiFkGnXl1Bz9Hx0epqX8Vlf IdDHpj4OLgfZAfw55L60g8QjutyXeSDIxAppok+PbOio56tAmiQrlDXw9ZTpapKw 7dpz3O/L8IrWnFVSBxXDbZXeKWsrh4rL171NEHz3RQP+uUe9DfMOMqecwVyQnLsb xEkwb7v54mzf7IjsZAIMYulj9F/xj0Kxt8CqhV6fRHDlAwObLSIUNoJ74YC9qr7q 44Tj50bk5k4/uITtUN5zw3k8JSzDQ==
X-ME-Sender: <xms:CN3BXdO-nm_4pdrk5oIef-jKVhLkD6iGbr-MHTf3QrTsnJHxX1ys0A>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudduhedgudeflecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgse htqhertderreejnecuhfhrohhmpedfvehhrhhishhtohhphhgvrhcuhghoohgufdcuoegt rgifsehhvggrphhinhhgsghithhsrdhnvghtqeenucffohhmrghinhepghhuvghsshdrtg homhdpghhithhhuhgsrdgtohhmpdhivghtfhdrohhrghenucfrrghrrghmpehmrghilhhf rhhomheptggrfieshhgvrghpihhnghgsihhtshdrnhgvthenucevlhhushhtvghrufhiii gvpedt
X-ME-Proxy: <xmx:CN3BXbaDvtQcbPRvyv_RIazvNM8b_PA9qgaPqnkXrNE_vkr-7JLhtg> <xmx:CN3BXf0t1M_oaxNQzPKrjIT5REwdoBUy9IY_OuZB5E7JbfdTypHutA> <xmx:CN3BXSsC7LxWufGrhL2xwJeipQSUf59lFYztt7oEM6BLmcesvozSDA> <xmx:CN3BXVWR_euDoXT7gu3kNcZ4u1lSQo282EDuk2oJSanwcG_cNZDPvQ>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 43B263C00A2; Tue, 5 Nov 2019 15:35:20 -0500 (EST)
X-Mailer: Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-509-ge3ec61c-fmstable-20191030v1
Mime-Version: 1.0
Message-Id: <>
In-Reply-To: <>
References: <>
Date: Tue, 05 Nov 2019 12:34:59 -0800
From: "Christopher Wood" <>
To: "" <>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [TLS] Proposals to address ESNI issues
X-Mailman-Version: 2.1.29
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, 05 Nov 2019 20:35:26 -0000

On Tue, Nov 5, 2019, at 12:28 PM, Christopher Wood wrote:
> Hi folks,
> Since Montreal, a few people have been working on the protocol issues 
> that currently exist in draft-ietf-tls-esni-05. To recap, here are the 
> problems we’re aware of:
> 1. Server Reaction Attacks. Servers that associate SNIs with tickets 
> may lead to dictionary attacks. An example is shown below. Adv connects 
> to S with a guess domain and receives a ticket. Upon 
> receiving a CH (with ESNI) from a victim client without any PSK, Adv 
> attaches its ticket and binder to the CH, and forwards it to S. If S 
> checks whether the ESNI in the CH matches that of the ticket and 
> proceeds or aborts accordingly, Adv can learn whether or not its guess 
> -- the SNI of the ticket -- matches that of the ESNI. 
> 2. HRR Binding Check Failure. If a server decrypts ESNI upon receiving 
> CH and then stores it even when it sends, HRR, then an on-path attacker 
> can intercept theHRR message, and swapping in its own KeyShare and 
> (valid) ESNI blob. If the server fails to check that the ESNI value 
> from the second CH matches that of the first CH. 
> 3. Probing Attacks. An on-path adversary changes fields in a 
> ClientHello not bound to the ESNI extension and observes server 
> behavior. If servers have different cryptographic configurations based 
> on SNI, this lets an adversary learn the SNI from the server’s choice 
> of parameters.
> The attacks on ESNI security above seem to stem from two problems: 
> 1. The ESNI contents are not fully bound to the ClientHello contents. 
> If this were not the case, attackers would not be able to modify 
> ClientHello messages, either by appending ticket (binders) or swapping 
> ciphersuites or other parameters.
> 2. The handshake secrets are not bound to the ESNI contents. If this 
> were not the case, servers could not choose attacker-controlled keying 
> material yet proceed with victim-controlled parameters (SNIs). 
> We try to capture these problems in the following definitions of 
> “forward” and “backward” binding. We say ESNI contents are 
> forward-bound to a handshake if it is not possible to decrypt handshake 
> messages without both the handshake shared secret and ESNI shared 
> secret (or a value protected by the ESNI shared secret, such as the 
> nonce). Likewise, we say ESNI contents are backward-bound to a 
> ClientHello if it is not possible to modify a CH in any way without 
> causing ESNI decryption.
> To give ourselves confidence that these are indeed necessary for ESNI 
> security (assuming other obvious properties such as “consistent 
> cryptographic configuration [2]”), we worked with Karthik Barghavan 

Correction: Karthik Bhargavan (my sincerest apologies for the typo, Karthik!)

> to model a simplified variant of TLS 1.3 with ESNI in ProVerif. A writeup 
> of the *preliminary* model and our findings is available at [1]. 
> To satisfy these requirements, there are currently four different 
> proposals on the table:
> - ESNI encoder/decoder [3]: Add encoding/decoding layer between client 
> and client-facing server that translates a “public” CH into a “private” 
> CH (and back), requiring servers to choose one of these CHs to complete 
> the handshake.
> - Tunnel CH [4]: Encrypt a “private” CH under the server’s ESNI key and 
> include it as an extension in an outer “public” CH, requiring servers 
> to choose one of these CHs to complete the handshake.
> - ESNI PSK binding with key schedule injection [5]: Bind CH contents to 
> ESNI via a unique PSK identity (backward binding), and bind the key 
> schedule to the ESNI contents (forward binding).
> - ESNI with external PSK import and key schedule injection [6]: Same as 
> above, except bind ESNI to the ClientHello using the external PSK 
> importer API. 
> We modelled #2 (Tunnel CH) and #3 (key schedule injection) and to give 
> us confidence in each design. (Note that #1 and #4 are variants of #2 
> and #3, respectively.) (And we are actively extending these models to 
> improve our confidence.)
> Please have a close look at the above PRs and weigh in. We’d like to 
> reach consensus on one design during (or before) Singapore. 
> Thanks,
> Chris (on behalf of the authors)
> [1] 
> [2]
> [3]
> [4]
> [5]
> [6]
> _______________________________________________
> TLS mailing list