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

Viktor Dukhovni <ietf-dane@dukhovni.org> Tue, 23 May 2017 17:50 UTC

Return-Path: <ietf-dane@dukhovni.org>
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 2519B129C53 for <tls@ietfa.amsl.com>; Tue, 23 May 2017 10:50:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 uEFnIwlxnl83 for <tls@ietfa.amsl.com>; Tue, 23 May 2017 10:50:54 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86ACA129AB3 for <tls@ietf.org>; Tue, 23 May 2017 10:50:54 -0700 (PDT)
Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id C244D7A32F1 for <tls@ietf.org>; Tue, 23 May 2017 17:50:53 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <55096b5d-dc74-fae4-57e3-83d4355d6050@huitema.net>
Date: Tue, 23 May 2017 13:50:52 -0400
Content-Transfer-Encoding: quoted-printable
Reply-To: TLS WG <tls@ietf.org>
Message-Id: <86A85A1E-A0A2-4692-ADB1-D5126E421B70@dukhovni.org>
References: <CAAF6GDcKZj9F-eKAeVj0Uw4aX_EgQ4DuJczL4=fsaFyG9Yjcgw@mail.gmail.com> <CABcZeBPuOupLTNKOtuCgOjYNdiuw571HM-pq1vNZz_8x-XX5mg@mail.gmail.com> <CABcZeBMqALJ10cU7FMUhv8k5Q=tw3yu1-5pdrKzOBM3=g5PHJw@mail.gmail.com> <20170519095316.GA30080@LK-Perkele-V2.elisa-laajakaista.fi> <CAAF6GDeuRMZx9MRynrxMp1fCvRS2jjr0vcqt0R89cJEkD6u=rQ@mail.gmail.com> <20170520101616.GC32428@LK-Perkele-V2.elisa-laajakaista.fi> <CABcZeBNj_X4qbXrH4732kQiAHrBpPZhW1nmn4Xnp-pm0gv1Psg@mail.gmail.com> <CAAF6GDcEKaBaJZU0q822KqoJDL5kyZJGbOBKsnU9tnpU=YvoxA@mail.gmail.com> <MWHPR15MB1182F59E2B60534CB20EC9C4AFF80@MWHPR15MB1182.namprd15.prod.outlook.com> <CAAF6GDeNWpKM_Uu5zN70gW9L=WSLZVJhi=OZwYOC3y24zuphpQ@mail.gmail.com> <f8f8db4a-7d4e-590b-25c2-b1cbac6b5313@huitema.net> <CAAF6GDcarzUXiEAxBm9RaLQT5A3B=2TPkngEavEY=wQMHU=9Gw@mail.gmail.com> <1c188f36-c197-20f7-48e4-5d75ac4a2211@akamai.com> <CAAF6GDfCRD3nQmr0JB75CxLkqjmDiWn9co0DXCJHwS3TK625WA@mail.gmail.com> <55096b5d-dc74-fae4-57e3-83d4355d6050@huitema.net>
To: TLS WG <tls@ietf.org>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/4raSj-pEF9VUOn-31xKKW8d8rOI>
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, 23 May 2017 17:50:56 -0000

> On May 23, 2017, at 12:52 PM, Christian Huitema <huitema@huitema.net> wrote:
> 
> Colm's point is that for many DNS servers, queries are not truly stateless. The answer to a query for AAAA records for example.net might vary over time, or even query to query, for example to manage load balancing. Adversaries can predict these variations. They can observe the state of the server before and after replaying 0-RTT data. If they observed that the 0-RTT data caused the answer to change, they can confirm that the 0-RTT data contained a request to that server.

The fix is to amend DNSpriv to require stateless (random rather
than say round-robit) RRset rotation.  With random rotation, the
next RRset order is independent of previous queries.

Secondly, even with the 0-RTT leak, while privacy against an active
attacker might not be assured for all users, there is fact privacy
for most users, especially against a purely passive adversary.

DNS privacy is always an imperfect security mechanism because
the DNS query will often at in the provider request to the
authoritative servers leak the user's "subnet" in the clear,
typically in the form of the containing /20 CIDR block to aid
load-balacing CDNs.  Then after the response is received, the
client will send IP datagrams that further narrow the set of
potential domains.  Then in visiting a website there'll be
unencrypted SNI, or predictable patter of response sizes and
consequent retrieval of CSS/javascript/image resources that
fingerprint the request.

Cryptography and 0-RTT are far from the weakest link in the
chain here.  DNSpriv is necessarily imperfect incremental
security, and defeating traffic analysis is exceedingly
difficult.

To the extent that DNSpriv over TLS happens at all, 0-RTT
will be used for DNS, and will be used statelessly (allowing
replays).  If there are sufficiently cheap ways to improve
security (e.g. random RRset rotation) without sacrifing
performance, increasing latency or adding complexity, then
by all means promote their adoption.

-- 
	Viktor.