Re: [TLS] Security review of TLS1.3 0-RTT

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Tue, 02 May 2017 20:55 UTC

Return-Path: <dkg@fifthhorseman.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 8B7F612EAB0 for <tls@ietfa.amsl.com>; Tue, 2 May 2017 13:55:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Level:
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham autolearn_force=no
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 ApbYBDZtTOTd for <tls@ietfa.amsl.com>; Tue, 2 May 2017 13:54:59 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id 38CBF129418 for <tls@ietf.org>; Tue, 2 May 2017 13:52:25 -0700 (PDT)
Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 6D9D6F993; Tue, 2 May 2017 16:52:25 -0400 (EDT)
Received: by fifthhorseman.net (Postfix, from userid 1000) id 13A4020662; Tue, 2 May 2017 16:52:21 -0400 (EDT)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: Nico Williams <nico@cryptonector.com>, Benjamin Kaduk <bkaduk@akamai.com>
Cc: TLS WG <tls@ietf.org>
In-Reply-To: <20170502195753.GJ10188@localhost>
References: <20170502173905.GC10188@localhost> <CAAF6GDeYc5o=eeeyV6HhK9vrLngB-Y=Ed5BdedrE8h2-py4oAw@mail.gmail.com> <20170502180049.GE10188@localhost> <CAAF6GDecd=x-Ob_eO1vSWr6cb6jAeyHBx7zf6cpX=GfxBosfLQ@mail.gmail.com> <20170502182529.GG10188@localhost> <466fad64-5acd-d888-1574-10f95b2ab7bc@akamai.com> <20170502192003.GH10188@localhost> <e313032d-2ac8-cc4e-0aa7-de869007e397@akamai.com> <20170502193145.GI10188@localhost> <42522b3c-8987-ea2a-2173-bcadaf6ff326@akamai.com> <20170502195753.GJ10188@localhost>
Date: Tue, 02 May 2017 16:52:17 -0400
Message-ID: <87a86vrnge.fsf@fifthhorseman.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/IKDE5u06bw4Ogvqo261614TYaa0>
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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, 02 May 2017 20:55:01 -0000

On Tue 2017-05-02 14:57:54 -0500, Nico Williams wrote:
> Well, I did say that to me there's not much difference to _me_ between
> "connections reusing the same ticket can be correlated to each other"
> and "connections reusing the same ticket can be correlated to each other
> and the connection whence the ticket".  Others might disagree,

I disagree, Nico! :)

The difference here is between saying:

 * clients that want the latency benefit of session resumption can be
   careful to avoid ticket reuse and their connections will be
   unlinkable to a network observer who records session IDs.

versus:

 * clients that want the latency benefit of session resumption must
   accept that a network observer can trivially know that each
   connection is linkable to the previous one.

put another way: the difference between 0 required backlinks and 1
required backlink on each individual session resumption is the
difference (for a cautious yet session-resuming client) between 0
connections linked by a network observer and all connections linked by a
network observer.

TLS session linkability is relevant:

 * When a client is behind a NAT and wants their connections to be mixed
   with (indistinguishable from) other clients behind the same NAT, to
   the perspective of a network observer outside the NAT.

 * When a client moves network locations and doesn't want their network
   position to be trackable by a network observer.

 * When a client uses a VPN as an encrypted Internet proxy (or uses Tor
   or some other similar IP-anonymizing service), and does not want a
   network observer outside the VPN from being able to distinguish their
   traffic from the traffic of other users of the anonymity network.

        --dkg