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

Martin Thomson <martin.thomson@gmail.com> Thu, 04 May 2017 00:25 UTC

Return-Path: <martin.thomson@gmail.com>
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 754FF129423 for <tls@ietfa.amsl.com>; Wed, 3 May 2017 17:25:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level:
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 ycL-xpnw8Fks for <tls@ietfa.amsl.com>; Wed, 3 May 2017 17:25:39 -0700 (PDT)
Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (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 0309A129409 for <tls@ietf.org>; Wed, 3 May 2017 17:25:39 -0700 (PDT)
Received: by mail-lf0-x22c.google.com with SMTP id h4so2576667lfj.3 for <tls@ietf.org>; Wed, 03 May 2017 17:25:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=vynZ2gfOoB2Ip/tEb8SehS/1db2MGSXsK4fHalqWWw4=; b=rOkcK6gICVjfXMwIAqRmhYyav2IyZCenm27KmZ4KM0V5v6+qnhdWM3AI6wtL43QolR D1TUfYKjq5dDZ7+pmhT9FuMX+XtmwNiBu8a581rJ7BV2UonVc6y0qH4z4zxa9U8lKob4 r/CpcF/T0MjXfmDBrzI2ll5lnHb1PxQ4rUWneVGx3HyeAQTugRjO/Ndlyig38DrSgbjr Jvbk4loHk+KN6y90GWoEZCd0zpxnHTdhCqIPb8LeEfLTDoDGnIbShBYxr82xF95+REZO iW1DrKoGcCva+k/LpLgQeofM1Xsd8gC1VtC5MmlaKBAhhUsbTSQtlCBMCQHMDV/NV7WI RmQg==
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:content-transfer-encoding; bh=vynZ2gfOoB2Ip/tEb8SehS/1db2MGSXsK4fHalqWWw4=; b=iPN/XZustecCdPdvEFwhpmNk33rY3gmgcHDgz2dQwy1IMtKUiksi8b7au7kZXR2+qB N0QJ1HTZs5J8pZ/uOdbXgC6pzjHQ89a7o3LS41RVpDzLTgrXAkd89e/amohuzo1vT62T OgqnGzID18+gGBC4V8ZRev3CTXFUjjSAPIcMesTTYr3Tgd3Y1GiI0/sIlQoqJTSzx3pm THCcFRPBdbR5jW5NlwBULpKBPzEnOWXc8mTi2wzioenbqu5pQJqi/LTlAa0fLhrTMhys vJuxdBm+i9vdf1jM/pJ2qJCgWOFqxBfh5YT2tRA5RzIfNl23dPFZFHZtVuc9Lx9sWNDF oMEQ==
X-Gm-Message-State: AN3rC/65knP5PoKlUpiCcTFt5LIIu389Injwxd7EK/vj7HPljkjkiVrv 3Selmy/XREOhaFrAHm/8Kppgy3fryw==
X-Received: by 10.25.158.147 with SMTP id h141mr13555646lfe.130.1493857537297; Wed, 03 May 2017 17:25:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.46.83.2 with HTTP; Wed, 3 May 2017 17:25:35 -0700 (PDT)
In-Reply-To: <CAAF6GDcnrQwQ7dE59pYV3YFLJD9zsQEqmPrFRKgyxSwj7UFCkA@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>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Thu, 04 May 2017 10:25:35 +1000
Message-ID: <CABkgnnV_d6hRaHxsGoFFGPU3rsrPKKy231To-VL9pWidWs04HQ@mail.gmail.com>
To: Colm MacCárthaigh <colm@allcosts.net>
Cc: Hannes Tschofenig <hannes.tschofenig@gmx.net>, "tls@ietf.org" <tls@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/SY-Fwbxi64IcFexIL3NjUMpvq-0>
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:25:40 -0000

On 4 May 2017 at 09:16, Colm MacCárthaigh <colm@allcosts.net> wrote:
>> We've historically done a lot to
>> secure applications at a single point, and we're almost at the end of
>> what we can reasonably do for them at this layer.  We need to think
>> more hollistically and acknowledge that applications need to take some
>> responsibility for their own security.
>
> No we don't. Servers can prevent replay.

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.

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.