Re: [TLS] Proposals to address ESNI issues

"Christopher Wood" <caw@heapingbits.net> Tue, 05 November 2019 20:35 UTC

Return-Path: <caw@heapingbits.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42F4E120B73 for <tls@ietfa.amsl.com>; Tue, 5 Nov 2019 12:35:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=AF6c5PcG; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=cD+5GV9U
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S5GIautHRKOZ for <tls@ietfa.amsl.com>; Tue, 5 Nov 2019 12:35:23 -0800 (PST)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BBF7120B87 for <tls@ietf.org>; Tue, 5 Nov 2019 12:35:21 -0800 (PST)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 7F04D2206E for <tls@ietf.org>; Tue, 5 Nov 2019 15:35:20 -0500 (EST)
Received: from imap4 ([10.202.2.54]) by compute6.internal (MEProxy); Tue, 05 Nov 2019 15:35:20 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; 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= messagingengine.com; 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: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-509-ge3ec61c-fmstable-20191030v1
Mime-Version: 1.0
Message-Id: <a8a394f7-0586-47cd-9865-429d8a64f056@www.fastmail.com>
In-Reply-To: <304108c8-e8cc-41a6-b931-d5c44cc812e4@www.fastmail.com>
References: <304108c8-e8cc-41a6-b931-d5c44cc812e4@www.fastmail.com>
Date: Tue, 05 Nov 2019 12:34:59 -0800
From: "Christopher Wood" <caw@heapingbits.net>
To: "TLS@ietf.org" <tls@ietf.org>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/KSCiRP0dtAp8WveHg9mM4uocelQ>
Subject: Re: [TLS] Proposals to address ESNI issues
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=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 guess.com 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] 
> https://github.com/chris-wood/encrypted-sni-model/blob/master/stable/esni_analysis_00.pdf
> [2] https://github.com/tlswg/draft-ietf-tls-esni/issues/178
> [3] https://github.com/kazuho/draft-rescorla-tls-esni/pull/1
> [4] https://github.com/tlswg/draft-ietf-tls-esni/pull/196
> [5] https://github.com/tlswg/draft-ietf-tls-esni/pull/197
> [6] https://github.com/chris-wood/draft-ietf-tls-esni/pull/9
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>