[TLS] Proposals to address ESNI issues

"Christopher Wood" <caw@heapingbits.net> Tue, 05 November 2019 20:29 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 DA067120B86 for <tls@ietfa.amsl.com>; Tue, 5 Nov 2019 12:29:01 -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=BeLvPKcL; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=YNuqhF4n
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 kMkPMwGf3ofw for <tls@ietfa.amsl.com>; Tue, 5 Nov 2019 12:28:59 -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 5FF09120B84 for <TLS@ietf.org>; Tue, 5 Nov 2019 12:28:58 -0800 (PST)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id ACEC521FFC for <TLS@ietf.org>; Tue, 5 Nov 2019 15:28:57 -0500 (EST)
Received: from imap4 ([10.202.2.54]) by compute6.internal (MEProxy); Tue, 05 Nov 2019 15:28:57 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:date:from:to:subject:content-type :content-transfer-encoding; s=fm2; bh=oUCTsBxRKiRqa0Mm6NfYOLSvEf hn5NLf90ArTdpfJ4c=; b=BeLvPKcLKAnWQamMOG7fhEtqSU0FQzUp9MHn08Sm+B ur87Nv8RXW3g2HWvPnwYbUEqzMkFy+ngxdaxp3VEGEIs3woFdTvULITX/EI18izK GBWH1bKzK8R3Gr5C9BYgy0byr6a0dDPogxRixVlCMy/pS5eAQxiDEWn7tK3puRrl to7JRWEH+MoItOWfjSdw5vKFwT7VTq8D157QXn+fo7srv+0PmCEmE9WrAGdW0a+K fpdleoEwprz238WXDXGHdjGCpWuER2KYGwByv1BZGFm6u8f1cjC0GPAGqLaBFFRy O2rJ17NZyE9kYofqc7vfkGra5eSGZL9PCnG6rpBqQF2g==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=oUCTsB xRKiRqa0Mm6NfYOLSvEfhn5NLf90ArTdpfJ4c=; b=YNuqhF4nWMIOCPkeWMo7VO mHFI+n49L/7Ab4RY55urhYTEWkwZ3Dgxc4L/J8KZo3TprhhyyE6/ZS6PVL4TyUBg Ysq8Li/c3a1gP0MoQYE1Q5h2KzEbTpFEazFdb5Drdxh+g/FQuH79+m1IsO7ZCjip 6+hfZEYLQkCFwa2ToQ6/EJSw+OSSSeaJUSyoEh9BHTyrIF+QOdcUJKQxPG5MeadX cs6JGjMhtF3JDoKkTUhZeA25ZqwhJxOszcx6FTIXzQpWJiw58CMxP16V0tkQFvcC C2oA+b6jhicuJEWC/3sldwK2RUHcPKqbTkaTFRlSYXvE0DUEol+ONuSfV5KhFKLA ==
X-ME-Sender: <xms:idvBXe_CM6O2euVzDCPaiGhyjkj05holydYZvNVUxr2JPmOmxPE35A>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudduhedgudefkecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgfgsehtqh ertderreejnecuhfhrohhmpedfvehhrhhishhtohhphhgvrhcuhghoohgufdcuoegtrgif sehhvggrphhinhhgsghithhsrdhnvghtqeenucffohhmrghinhepghhuvghsshdrtghomh dpghhithhhuhgsrdgtohhmnecurfgrrhgrmhepmhgrihhlfhhrohhmpegtrgifsehhvggr phhinhhgsghithhsrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd
X-ME-Proxy: <xmx:idvBXW1qzbCGg-ENG-3VtRWTG_l3qlqDtzQWG_W77y3_ocEWA2rGYw> <xmx:idvBXW7y5KvaoKje0pjCENv_-X4IjrnAVIXd3-vh-Mwf0-_IeBApEA> <xmx:idvBXcsMRL_A4TIU2cebZGgkr1N9U-nRXeggHqpKo2jrfB6Q9uk1QA> <xmx:idvBXZ-YUkOaa2d6482C-rFhuWOphI6jH_3D7S1rmMtLg_zscVs_Dg>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 6D7723C00A1; Tue, 5 Nov 2019 15:28:57 -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: <304108c8-e8cc-41a6-b931-d5c44cc812e4@www.fastmail.com>
Date: Tue, 05 Nov 2019 12:28:24 -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/FBmfwJS22iPfMU3omH9qr-vdAMM>
Subject: [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:29:02 -0000

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