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

Viktor Dukhovni <ietf-dane@dukhovni.org> Tue, 23 May 2017 18:27 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 A537312E042 for <tls@ietfa.amsl.com>; Tue, 23 May 2017 11:27:48 -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 Y8LGxQmcrHzI for <tls@ietfa.amsl.com>; Tue, 23 May 2017 11:27:47 -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 D3AAE12E03E for <tls@ietf.org>; Tue, 23 May 2017 11:27:46 -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 2ED647A32F1 for <tls@ietf.org>; Tue, 23 May 2017 18:27:46 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <CAAF6GDeum-XLt+f3_q9CRabC7Ro_0quu90jWVhaWeYbJntfzZA@mail.gmail.com>
Date: Tue, 23 May 2017 14:27:45 -0400
Content-Transfer-Encoding: quoted-printable
Reply-To: TLS WG <tls@ietf.org>
Message-Id: <9112D389-2D1B-4966-90A1-0DD4756EFF31@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> <86A85A1E-A0A2-4692-ADB1-D5126E421B70@dukhovni.org> <CAAF6GDeum-XLt+f3_q9CRabC7Ro_0quu90jWVhaWeYbJntfzZA@mail.gmail.com>
To: TLS WG <tls@ietf.org>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/VDhMj1-SBDEiin4omCYqli6L3XA>
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 18:27:49 -0000

> On May 23, 2017, at 2:07 PM, Colm MacCárthaigh <colm@allcosts.net> wrote:
> 
> That's not good for users, and seems like another very strong reason to make it clear in the TLS draft that that it is not secure. FWIW; DNSCurve includes nonces to avoid attacks like this: https://dnscurve.org/replays.html (which means keeping state).

Actually, nonces in DNScurve protect clients from replayed server responses (clients
are stateful).  I see no explicit guidance to detect or refuse replays of client
queries in DNScurve.  While servers could keep a nonce cache, in practice there
are multiple servers and they don't share state (no "strike registers").

The replays discussed in the URL you provide are replays of stale, but still
within signature validity DNSSEC server responses.  Not replays of requests.

-- 
	Viktor.