[TLS] Alternative ESNI?
Nico Williams <nico@cryptonector.com> Sat, 15 December 2018 02:53 UTC
Return-Path: <nico@cryptonector.com>
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 424EB130ED9 for <tls@ietfa.amsl.com>; Fri, 14 Dec 2018 18:53:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com
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 U_8AA8iUWKer for <tls@ietfa.amsl.com>; Fri, 14 Dec 2018 18:53:54 -0800 (PST)
Received: from palegreen.birch.relay.mailchannels.net (palegreen.birch.relay.mailchannels.net [23.83.209.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3B8412D4ED for <tls@ietf.org>; Fri, 14 Dec 2018 18:53:53 -0800 (PST)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 033025C37DE; Sat, 15 Dec 2018 02:53:52 +0000 (UTC)
Received: from pdx1-sub0-mail-a74.g.dreamhost.com (unknown [100.96.33.121]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id B39FB5C24CD; Sat, 15 Dec 2018 02:53:51 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from pdx1-sub0-mail-a74.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.16.2); Sat, 15 Dec 2018 02:53:51 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com
X-MailChannels-Auth-Id: dreamhost
X-Cure-Inform: 17134c00396bdd73_1544842431848_3435658283
X-MC-Loop-Signature: 1544842431848:1122635838
X-MC-Ingress-Time: 1544842431848
Received: from pdx1-sub0-mail-a74.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a74.g.dreamhost.com (Postfix) with ESMTP id 77B098003F; Fri, 14 Dec 2018 18:53:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:subject:message-id:mime-version:content-type; s= cryptonector.com; bh=idJV/NovR8C/p+8BF5Z6K97PUsI=; b=kcOGNjZ/Wb6 5UE7UTZxjLe7RKw81yLVcF2s3dQ8pj0ph/fPLcy3JkOAtH4BiYqTeNuBQgOruoZI 9Rey3rM3PtyfudTxINONeoy9KdjXwz5hzcGI33pEsMeVsn8G4DVcVd3aBsu7Ef9q ZRvca7O46MuYJpKyxGYgf+DkMnGH9Wq8=
Received: from localhost (unknown [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a74.g.dreamhost.com (Postfix) with ESMTPSA id DBA3E7F749; Fri, 14 Dec 2018 18:53:50 -0800 (PST)
Date: Fri, 14 Dec 2018 20:53:47 -0600
X-DH-BACKEND: pdx1-sub0-mail-a74
From: Nico Williams <nico@cryptonector.com>
To: tls@ietf.org
Message-ID: <20181215025346.GJ15561@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.5.24 (2015-08-30)
X-VR-OUT-STATUS: OK
X-VR-OUT-SCORE: 0
X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtkedrudehiedgheduucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkgggtuggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecukfhppeekrddvrddutdehrddujeenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpeekrddvrddutdehrddujedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/KjF6j5vasZp1rJl66Far4Wsp2g4>
Subject: [TLS] Alternative ESNI?
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: Sat, 15 Dec 2018 02:53:57 -0000
OpenSSL extracts and uses SNI from session resumption tickets. This gave Viktor Dukhovni and Matt Caswell an idea that I'll relay here on their behalf. Also, while we're at it, I'd like to note that SNI is not the only thing requiring privacy protection from the client. There's also the PSK identity payload for non-resumption PSKs... Not as important as SNI, perhaps, nonetheless I think we should maximize privacy, else we'll be engaging in repeated encrypted-{fill-in-the-blank} exercises. Our proposal makes DNS optional (for co-tenancy fronting discovery) and DNSSEC not necessary. The basic idea is to use a HelloRetryRequest to make a handshake traffic secret available to the client for it to use in its subsequent hanshake messages. This form is susceptible to an SNI disclosure active attack -- same as the current ESNI proposal w/o DNSSEC. This variant adds one round-trip to full handshakes. We can then optionally piggy-back the server's Certificate and CertificateVerify along with the HelloRetryRequest (provided the client's initial key_share is acceptable to the server), and now we have authenticated the server under its fronted name, which means there is no active attack on the ESNI. This still only adds just the one round-trip to full handshakes. And look ma', now w/ no DNSSEC requirement to avoid active attacks. And if the client already knows about the co-tenancy of the fronting and desired servers, then no DNS lookups are needed to discover it. E.g., dissidents might learn this by word of mouth. The second variant can, sadly, add an extra round-trip when the server finds the client's initial key_share unacceptable. As to resumption, the real SNI should be the one from the original full handshake, and the SNI in the resumption should be the fronting service's name. Resumption retains the same latency as in RFC 8446. Below are the flows for the three cases, all of these being full handshakes. Naturally, these should be read after first reading figure 2 from RFC 8446. ClientHello + key_share --------> HelloRetryRequest <-------- + key_share ClientHello {EncryptedExtensions} + key_share --------> {EncryptedExtensions} {CertificateRequest*} {Certificate} {CertificateVerify} {Finished} <-------- [Application Data*] {Certificate*} {CertificateVerify*} {Finished} --------> [Application Data] <-------> [Application Data] Figure 1: Alternative ESNI w/o active protection ClientHello + key_share --------> ServerHello + key_share {EncryptedExtensions*} {Certificate} {CertificateVerify} <-------- {HelloRetryRequest} ClientHello + key_share {EncryptedExtensions} --------> {EncryptedExtensions} {CertificateRequest*} {Certificate} {CertificateVerify} {Finished} <-------- [Application Data*] {Certificate*} {CertificateVerify*} {Finished} --------> [Application Data] <-------> [Application Data] Figure 2: Alternative ESNI w/ active protection ClientHello + key_share --------> HelloRetryRequest <-------- + key_share ClientHello + key_share --------> ServerHello + key_share {EncryptedExtensions*} {Certificate} {CertificateVerify} <-------- {HelloRetryRequest} ClientHello + key_share {EncryptedExtensions} --------> {EncryptedExtensions} {CertificateRequest*} {Certificate} {CertificateVerify} {Finished} <-------- [Application Data*] {Certificate*} {CertificateVerify*} {Finished} --------> [Application Data] <-------> [Application Data] Figure 3: Alternative ESNI w/ active protection, with worst-case latency Thoughts? Is this horrible somehow? Has this been discussed and discarded for some reason? Nico --
- [TLS] Alternative ESNI? Nico Williams
- Re: [TLS] Alternative ESNI? Eric Rescorla
- Re: [TLS] Alternative ESNI? Nico Williams
- Re: [TLS] Alternative ESNI? Stephen Farrell
- Re: [TLS] Alternative ESNI? Eric Rescorla
- Re: [TLS] Alternative ESNI? Viktor Dukhovni
- Re: [TLS] Alternative ESNI? Stephen Farrell
- Re: [TLS] Alternative ESNI? Viktor Dukhovni
- Re: [TLS] Alternative ESNI? Eric Rescorla
- Re: [TLS] Alternative ESNI? Eric Rescorla
- Re: [TLS] Alternative ESNI? Paul Wouters
- Re: [TLS] Alternative ESNI? Eric Rescorla
- Re: [TLS] Alternative ESNI? Nico Williams
- Re: [TLS] Alternative ESNI? Stephen Farrell
- Re: [TLS] Alternative ESNI? Viktor Dukhovni
- Re: [TLS] Alternative ESNI? Nico Williams
- Re: [TLS] Alternative ESNI? Nico Williams
- Re: [TLS] Alternative ESNI? Kathleen Moriarty
- Re: [TLS] Alternative ESNI? Eric Rescorla
- Re: [TLS] Alternative ESNI? Viktor Dukhovni
- Re: [TLS] Alternative ESNI? Kathleen Moriarty