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

Colm MacCárthaigh <colm@allcosts.net> Mon, 22 May 2017 17:56 UTC

Return-Path: <colm@allcosts.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 E2151127137 for <tls@ietfa.amsl.com>; Mon, 22 May 2017 10:56:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.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 Bb_In7mBgtsn for <tls@ietfa.amsl.com>; Mon, 22 May 2017 10:56:21 -0700 (PDT)
Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 312EC1270AC for <tls@ietf.org>; Mon, 22 May 2017 10:56:21 -0700 (PDT)
Received: by mail-yw0-x229.google.com with SMTP id l74so63590370ywe.2 for <tls@ietf.org>; Mon, 22 May 2017 10:56:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=P02zQw0xL+OuVAhbU9dD8I/LJKgABfj6510XIVdwzKU=; b=0Vbn5rG1lxv/1KSOAmvwsNxQGqhk4bEaA7uMeIVh3MWy3Hv+5NzKbQP0i/b+l7H7EM dbc+VcpDd55j3TKql5w94sPIkU+nSW4H8EGQjc3b3Ct0KgZa0q2QHC/yNHuVVOYVUU8d ncPbk/fxayOe10shIkett+dQ7QU1l8xrHpo3OIhIWSVmFoqSpke0zvCtoQOeWDB/qfS1 1+wTeodds+Sl9D8gPS02DF/eC3714X7cmabJYtM2p5zlIbrVlmKCL3o9UmPiZvd5RAcM K3cUILNAkOZsAvP2Wmz/12dFRRaf4hAcPzI0BH4Ip59HQLmCBED4uPl4YN8GZAf4Uhsg LFxg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=P02zQw0xL+OuVAhbU9dD8I/LJKgABfj6510XIVdwzKU=; b=fZkVxguBDGQImU6+Wu87chL1xj9FHFTpQwnapdAqy+HUtC3Io/f1uOD+Wyyet8j1xR Tumn9gHO8IGl4NfkHPiXQ4+q4yguobigNyyOIEk01NQ/VPIm/ggnrAgOXU1EYKAX817R 9O8XjTQYSrbbB5BZGRUQ3hyerdle4qhmzq3RyS19Ie2OVoXXUpdaCt2pxuC4NbD+jfv5 56Qq8y6eHpmXo7zKqZ6/1SkDI0rpMO4WgPShndmGnlDy6EnDTHL72TL5zMggInDKftBx gsZ+h4iFMhYx1CiiGyNrgXHv/RDh2hmzLgJbt3Xakgai1zIXEjjb3dbUCG5+hvX1rryO GHnw==
X-Gm-Message-State: AODbwcDVI5DYcMRRBvtPqcpmRA7vS0w4T3H0+HFQCbMwTWNjC3IRClbI AzhWGYh3jabkVTy/sZGBxIrhCiVXTQ91
X-Received: by 10.129.152.68 with SMTP id p65mr19409630ywg.1.1495475780437; Mon, 22 May 2017 10:56:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.93.70 with HTTP; Mon, 22 May 2017 10:56:19 -0700 (PDT)
In-Reply-To: <f8f8db4a-7d4e-590b-25c2-b1cbac6b5313@huitema.net>
References: <CAAF6GDcKZj9F-eKAeVj0Uw4aX_EgQ4DuJczL4=fsaFyG9Yjcgw@mail.gmail.com> <CABcZeBNcnW9zEPZ4mEje1_ejR3npNFz65rw-6qUPn7cQt1Nz9w@mail.gmail.com> <CAAF6GDe1_ih1aUShrzAHUuTzbLx6+0BdVexpGnq90RZsST8GvA@mail.gmail.com> <CABcZeBOX5NXuhgfap2S0naO9PFXv+K-+fZVPbgck6yciVnrYbQ@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>
From: Colm MacCárthaigh <colm@allcosts.net>
Date: Mon, 22 May 2017 10:56:19 -0700
Message-ID: <CAAF6GDcarzUXiEAxBm9RaLQT5A3B=2TPkngEavEY=wQMHU=9Gw@mail.gmail.com>
To: Christian Huitema <huitema@huitema.net>
Cc: Kyle Nekritz <knekritz@fb.com>, "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c0ba6caa9dee00550209608"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/GkG_80R1ZPIcrNjwS5jAQA7M4io>
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: Mon, 22 May 2017 17:56:23 -0000

On Mon, May 22, 2017 at 10:46 AM, Christian Huitema <huitema@huitema.net>
wrote
>
> Check DKG's analysis of 0-RTT for DNS over TLS: https://www.ietf.org/mail-
> archive/web/dns-privacy/current/msg01276.html. There is only one point of
> concern, a minor privacy leak if the DNS queries in the 0-RTT data can be
> replayed at intervals chosen by the attacker. The idea is to replay the
> data to a resolver, and then observe the queries going out to authoritative
> servers in clear text. The correlation can be used to find out what domain
> the client was attempting to resolve. The attack requires "chosen time" by
> the attacker, and thus will probably be mitigated by a caching system that
> prevents replays after a short interval.
>


I have a reply to that too, linked at the bottom: there's actually a more
trivial side-channel (due to non-idempotence) that hadn't been considered
in the original analysis.

I've yet to find /any/ example application where 0-RTT replay would
actually be side-channel free.

-- 
Colm