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

Colm MacCárthaigh <colm@allcosts.net> Thu, 04 May 2017 00:50 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 B453B129465 for <tls@ietfa.amsl.com>; Wed, 3 May 2017 17:50:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.101
X-Spam-Level:
X-Spam-Status: No, score=0.101 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 UpAZV_rXc5FU for <tls@ietfa.amsl.com>; Wed, 3 May 2017 17:50:36 -0700 (PDT)
Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (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 6ECD21250B8 for <tls@ietf.org>; Wed, 3 May 2017 17:50:36 -0700 (PDT)
Received: by mail-yw0-x22b.google.com with SMTP id 203so2824422ywe.0 for <tls@ietf.org>; Wed, 03 May 2017 17:50:36 -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=JVOz+fn6bu9u2DtljW9mpZJFMrXhUtVCtERmztvSf9I=; b=UPHU+B6GXwNwsubt3lUZ26vfPc43m4n2BHxDR10KHQOdqznctrqOgmV3UADBhv8UEr L/8hOCAJTd3KP6HN17NsE8bY0Eg5t7y4AT7KYZgNfd3NlxFPncoZbM2+rvWUsAXRMlgC WvoBcUvyK/Rds298uVqeNNXgjLFVkqydwftEyX3MXjs8XE72AzFOkpj+iOycpsLmWIda 4eGlEOG7aEULFhkYZHk6d1F8uT5cX0V4/dY5vNN2Z+A3TNaHy+n7OW0Cw3RvhKWYG/vU iuWmZxxpCuM7A2ExCcVBRZlHvPKnUHsDo/3za9sKSCvEXIh5ur3zgWWUCjw8m7CGBUIq Sqyw==
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=JVOz+fn6bu9u2DtljW9mpZJFMrXhUtVCtERmztvSf9I=; b=Huxds2hvuZa+bpnMBCJDA72LfKJb8EcLOGypmQdugQpRxZrLvHQ/rbauoMjStIxPnM 2KFnp6/yz5Ebjm9Bna2POWQ/DemtdP8JfH8FVJciW0BbgLSFlmA3wsHIU50m1p3mD9yS vaLxgFSkLCZblaBkhU7P6qBHoSDnqNuqbSIewqD29bCHetUJHZGWD+Iqba91wwJo1TZm n6xOWpe/aDH3iri+yRCg1B4+n5UEjgMfob4W4F2+U4fcd4Qzgb2M3wcskQr1MlT3Spdu b+DUupt+TQ2sziGASzNWgblc9wc2bi+NRHh7EvthzsnuyoXIQxqtSaImTNQw6EW45Lw5 P0Vw==
X-Gm-Message-State: AN3rC/4DjmWdc+Nwr9MAztFCKARHCIGdBjGsupn254emrV1GWPzamwOi TLl8chuYMGZNIcGwaXMbfB0FRuqnIA==
X-Received: by 10.129.53.207 with SMTP id c198mr34771903ywa.14.1493859035572; Wed, 03 May 2017 17:50:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.57.67 with HTTP; Wed, 3 May 2017 17:50:34 -0700 (PDT)
In-Reply-To: <CABkgnnV_d6hRaHxsGoFFGPU3rsrPKKy231To-VL9pWidWs04HQ@mail.gmail.com>
References: <CAAF6GDcKZj9F-eKAeVj0Uw4aX_EgQ4DuJczL4=fsaFyG9Yjcgw@mail.gmail.com> <cb518e35-c214-d11d-a068-c454b2e7ea6a@gmx.net> <CAAF6GDfQ+YXV4gvhBOOZKC=wtYhxQUy1_2_M+dgfbdL25pppiQ@mail.gmail.com> <CABkgnnUwTe627vY=hoLTRv1qmFQLf8ba64X8xHwYdtw7WYn5jw@mail.gmail.com> <CAAF6GDcnrQwQ7dE59pYV3YFLJD9zsQEqmPrFRKgyxSwj7UFCkA@mail.gmail.com> <CABkgnnV_d6hRaHxsGoFFGPU3rsrPKKy231To-VL9pWidWs04HQ@mail.gmail.com>
From: Colm MacCárthaigh <colm@allcosts.net>
Date: Wed, 03 May 2017 17:50:34 -0700
Message-ID: <CAAF6GDdPt7rkA=6aEB2=u4eAjZ2gAyR_ANDfDCQMCO-BCu2fDQ@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Hannes Tschofenig <hannes.tschofenig@gmx.net>, "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="001a1142e7ec2908ee054ea82956"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/HpEbYlmhufEu2m_0JCw4OLZz5TI>
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: Thu, 04 May 2017 00:50:38 -0000

On Wed, May 3, 2017 at 5:25 PM, Martin Thomson <martin.thomson@gmail.com>
wrote:

> I was responding to an overly broad statement you made.  In the
> discussion you also talk about timing side-channels and other ways in
> which information can leak.  Nothing we do at the TLS layer will
> prevent those from being created in applications.
>

Sure, but things we're doing at the TLS layer can make it  much worse, as
in this case. I don't think we can make attacks easier.


> Also, it might pay to remember that this is part of a larger context.
> Applications routinely retry and replay; if they didn't, users would.
>

In the larger context, not all HTTP calls are coming from user actions, or
from clients that retry in that way. Some clients need to be careful,
precisely to achieve idempotency or safety. The review details the reasons
why, and also why it is impractical for actors to separate out these cases
and simple "not use" 0-RTT, due to how layers work and systems
interoperate.

-- 
Colm