IETF Logo Mail Archive

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

Colm MacCárthaigh <colm@allcosts.net> Fri, 19 May 2017 20:18 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 9A87312945A for <tls@ietfa.amsl.com>; Fri, 19 May 2017 13:18:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.199
X-Spam-Level:
X-Spam-Status: No, score=-1.199 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 JVH-l0CoMGHP for <tls@ietfa.amsl.com>; Fri, 19 May 2017 13:18:31 -0700 (PDT)
Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (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 ECCE5124BFA for <tls@ietf.org>; Fri, 19 May 2017 13:18:30 -0700 (PDT)
Received: by mail-yw0-x22f.google.com with SMTP id l14so39739456ywk.1 for <tls@ietf.org>; Fri, 19 May 2017 13:18:30 -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=/96ZD0HZAe7UH1q+dTszIRABA+9Mbd9yT4HIwW5saBo=; b=AevEvDGe+sesn+8xl3o4doXWWpoV1urynduvqE+aC+FaDPhtLbu/BYrbSrFiZ1gqcK kMfOJxI27vhPVDszXrWuHJSueLA9BW+cVFj/D5A/vJyq/4ojo2YQk1VNSsBCjlqv8qk6 Vl9+olJ5SaHbscyK2ng7NlYgEh2fRMRIFzTGZ251r7Vheb6VAmAi5Yjygu9xOzxoedIi Bloql3wvTxEQ7dcM5aA5PVvBuqCmnkr0zWVjjifKulVjyEoklzJA7LTytrLty1gR1RNz qNXzw2Rd4+CCv1yhE+e1O3/FeiZjqHNKTst1U3rNjivtvcyJ3n7cABhwbGS3Cu6h8gnG KVug==
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=/96ZD0HZAe7UH1q+dTszIRABA+9Mbd9yT4HIwW5saBo=; b=fGrfRgFaiPsHTC3qBBFWagtGSFkSEbIfjT51z38y2kayoCvsjrEnqk+LPTfsmhTCZZ Ogy4b8drgsUZossYsehsYji2qvvgYMjQhRQ0q9mVmXRc/GY+iPiOjwBNhfPK3/Q6Y4kq sOtT0xn6ckmSdEgBOs3kFSqKoifeFE5Rcwy0V4sABLWAutoTxv5p85t0CGn5mmeAus3s pMrcKQvwtFsxr9DIqU57/2WUYPT07hgwODCrZFzLTPPpuqsyVsWKd0OwX6iIxGOOThnw pcJIm1d5slvaQzZvKdke/A24nl6sjRJFDPba+pq8CCViDSzFj2BenDWHQiss2VGhnONY Hzig==
X-Gm-Message-State: AODbwcCBSucjLtytupRcd+EpeTOwrAqe9QQ/mysogZpiAhIeIwf/Nfi2 tdFYUVAHINCHc4FeL58gmBjRBypDVRO9
X-Received: by 10.129.157.142 with SMTP id u136mr10101724ywg.323.1495225110203; Fri, 19 May 2017 13:18:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.57.67 with HTTP; Fri, 19 May 2017 13:18:29 -0700 (PDT)
In-Reply-To: <CABcZeBNQXGFXZJtX74zrx2V63tWBhvSQkYSrpYFdOOA=y81mOQ@mail.gmail.com>
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> <20170519184051.GA31741@LK-Perkele-V2.elisa-laajakaista.fi> <CABcZeBNQXGFXZJtX74zrx2V63tWBhvSQkYSrpYFdOOA=y81mOQ@mail.gmail.com>
From: Colm MacCárthaigh <colm@allcosts.net>
Date: Fri, 19 May 2017 13:18:29 -0700
Message-ID: <CAAF6GDc9JZJV7CdevQUNLb9uAdLuumnYBn1Ce76xJt1UG=MPxA@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: Ilari Liusvaara <ilariliusvaara@welho.com>, "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c0b68aa8ddfca054fe6399d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/DSsntirAxuM3n3zjRvswgifHgmk>
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: Fri, 19 May 2017 20:18:33 -0000

On Fri, May 19, 2017 at 11:44 AM, Eric Rescorla <ekr@rtfm.com> wrote:

> Yup. There are no known reasons that prevent at-most-once 0-RTT delivery,
>
>> even with distributed servers for the origin.
>>
>
> I don't disagree with that necessarily, but if the client responds by
> retransmitting
> in 1-RTT, then you don't have overall at-most-once.
>

Obviously this is fine for browsers; retry's make sense there anyway, and
so if we prevent mass-replay then there are no new attacks like the
side-channels and DOSes.

If a client needs to be more careful; with a hard-time limit on ticket use,
it can actually reason its way to at-most-once. It needs to wait out the
time limit, then do a read; to see if the original attempt succeeded or
not, and only then retry. That's a fairly common mode in eventually
consistent systems, loss-tolerant protocols and distributed consensus
protocols. For example some S3 clients and PAXOS systems work like this.

Of course it's very inconvenient to have to sometimes block for 10 seconds
(or whatever we pick), in return for a speed up of maybe as much as ~200ms
in the "ordinary" case; but it's the kind of trade-off that an
instrumentation system might make; like an industrial controller - where
day-to-day system liveness is a massive optimization benefit and the
occasional interruption is no big deal.

Super esoteric, and maybe we shouldn't even think too much about it, but I
bring it out because that construction is the only one I've found that gets
to at-most-once delivery; and it highlights that the existing system
explicitly doesn't and might just be needless complexity (the multiple
streams signaling).

-
Colm

v2.23.0 | Report a Bug | By Email