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