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

Colm MacCárthaigh <colm@allcosts.net> Tue, 23 May 2017 18:38 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 2C70612DDD2 for <tls@ietfa.amsl.com>; Tue, 23 May 2017 11:38:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 liOHTw3H9Ps0 for <tls@ietfa.amsl.com>; Tue, 23 May 2017 11:38:49 -0700 (PDT)
Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (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 B9DB012940C for <tls@ietf.org>; Tue, 23 May 2017 11:38:49 -0700 (PDT)
Received: by mail-yw0-x22e.google.com with SMTP id b68so78857930ywe.3 for <tls@ietf.org>; Tue, 23 May 2017 11:38:49 -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; bh=FAMujmr33fmyKkmz/t/zVghynI8/++eCyKUEtal8N+U=; b=ni2V33Za4XAoSThljlZmfy7G8xQbWG/97PTdhhgwpos+nYHOvTvUetv9s+S1YuRC9h x9Ow3gxHhKPP/Y7DwM+yzUgvKVSAODs/zJ0au+zZGpQnca7MR5kRjyEKWSelnkHTDWFZ NONYgLbSHyoLgyGJyLLpzYU8Voe8ElofEyDrvDF6SUAzynuj0Sc8XWV/NfVlqvrP4+Kl C9f74V1po4EFA7lDlxp83ZwwX7k5wSMAhG1JmzEsBQZUjaQ4ZwLx5obOy6+/g74bsh7X /5IO29wWzr3MlH4b+XvFilFtJNFfp43XJ0el8JS/WoR7Tdimu5LGqVk80LlZhCkeEUlP VC/w==
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; bh=FAMujmr33fmyKkmz/t/zVghynI8/++eCyKUEtal8N+U=; b=q1CSf6XMWGuSiV3pL/90BgE8S7jZeN2HtJ8sORabsdJ2nc/zy5bgquJFBxKNTOOxul PpTZ2dy/kq2aWUtQRehzl9Usy3shgGj8elfFQwuSruQs5XjyqufX1lShm2txi/+52psH lwl2wr/QiKEtfcJicnCqwmRHQR5XWUTMW/dVnqF3eCgAnF0lxJAJVHXtO5ezBSpjuaQN kDmUTKmRQ2YNKDzraFpbR9Gxk/XFFZ4zBCly5rOKJXIyieoTzkR/RGEkV2LmR0a4K3hl STuzz7jDNLEnKHG3qHImkdwnOGp4vMb7jjtM3yxTirB4+fkVvbD5UCxLGqwxWghb+iUJ Qmjw==
X-Gm-Message-State: AODbwcAtFD35HZnlo//qYUQGuJo8aXG8ZUfFPFbFy3mHnRuL8f+rnock dR2v6Hj1HQxkwskzY+p6CgUcFLOyD7Y4MyQ=
X-Received: by 10.13.236.206 with SMTP id v197mr24076351ywe.296.1495564728570; Tue, 23 May 2017 11:38:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.93.70 with HTTP; Tue, 23 May 2017 11:38:47 -0700 (PDT)
In-Reply-To: <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> <9112D389-2D1B-4966-90A1-0DD4756EFF31@dukhovni.org>
From: Colm MacCárthaigh <colm@allcosts.net>
Date: Tue, 23 May 2017 11:38:47 -0700
Message-ID: <CAAF6GDczkYOzDt7PGuA0VkOY67sSaRHwDmHT8+07Fz3OGZTzwA@mail.gmail.com>
To: TLS WG <tls@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c0870f262bd8b0550354cff"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/1eWn7MewvBz8nYl626Z0FkQdHDs>
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:38:51 -0000

On Tue, May 23, 2017 at 11:27 AM, Viktor Dukhovni <ietf-dane@dukhovni.org>
wrote:

> 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").
>

My apologies, you're right! I'll make sure to tease djb now. That's still
an insecure design (or at least a privacy defeating design) for the same
reasons as earlier. Though tinydns doesn't do RRL or Cyclic answers, so in
that coupled implementation it may be ok.

At one time we didn't think the kinds of side-channels present in TLS were
a big deal; the "it is not believed to be large enough to be exploitable" note
in section 6.2.3.2 of RFC5246 comes to mind. Here we risk repeating history.

-- 
Colm