Re: [TLS] Closing on 0-RTT
Eric Rescorla <ekr@rtfm.com> Fri, 30 June 2017 16:54 UTC
Return-Path: <ekr@rtfm.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 86A75130A92 for <tls@ietfa.amsl.com>; Fri, 30 Jun 2017 09:54:13 -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=rtfm-com.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 I56Cl1m8dCGy for <tls@ietfa.amsl.com>; Fri, 30 Jun 2017 09:54:10 -0700 (PDT)
Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (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 A297D12ECF5 for <tls@ietf.org>; Fri, 30 Jun 2017 09:54:10 -0700 (PDT)
Received: by mail-yw0-x236.google.com with SMTP id j11so51496250ywa.2 for <tls@ietf.org>; Fri, 30 Jun 2017 09:54:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wKjVcIEczeLxNCx3uURSSzZHF3UMEoLjlYjW3XtvmAI=; b=bdpDANCCzz/PzWPFggdlyZ2a+HReEM0VQXW1DrEYjvXYofAPYCSzrU/gAowr9Azk4T V3Xt630/uMKuF+dwgz1GbxeydAlhZg0xK+LMPeecLwPbSyAZDvg/XsSIcmGQPDM2drJP qnp/XKYqXc8g+2clzQ7jYeo4xQ+cy5e4YFqUdHcMVzPYV3L8ypT6xoXmIsoHbBTzxx14 5ER4dY+FKwn0hcYZeFzPGTHRohQDsr+43y4sKQMA8hGJp+G8/GlVu+SZZErJG4uYfyd7 pGs1xL8du+bw9tONTlO3GLfECcvelsOer2D2pydOOjMswH4GyJzG8S2KtacOzvpVAhK3 Kjvw==
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=wKjVcIEczeLxNCx3uURSSzZHF3UMEoLjlYjW3XtvmAI=; b=cvPlexIAeYHjDhxhYPptgmKAGIIsc7/qan+rRtNVHOLOHPu0dkjNCumA5iTz6MCbl7 OB6CMrbVoqmFCEtsALqTXQ0MBoIeN3vPowucCEXXqa1wptX4R22UaN5/JDw8JlG+bh4h UBbtv31cQ2vP9d+52/dxylt3+M6zM0cAdfWIAA1itAlkenpHd04uvRVh9snXnbPWQXtD 48NtqaYcMGS9ToSaXOHhvfzf6UI2QTHFOY9YAD5U4KyNK6++E3iLaOPhUUzPDkFVzq3d TPUyuIPlMIZg9BwOaHqO+GYenkmualkalJdPnbgcpUhxhN6gkVQbXL6boDMdUDdN0QbI /i0Q==
X-Gm-Message-State: AKS2vOx1AvgCNvE1YDHNRKw9oi43KmJeSYamiFIVLa7SK46WLsXQqNRR iRQoo6r2kaVu/gWXiiaF1T83t6AjNTfW
X-Received: by 10.129.109.206 with SMTP id i197mr10476222ywc.24.1498841649858; Fri, 30 Jun 2017 09:54:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.13.215.9 with HTTP; Fri, 30 Jun 2017 09:53:29 -0700 (PDT)
In-Reply-To: <7b5b28f1-60d5-0979-f789-0471df33dba9@akamai.com>
References: <CABcZeBNLo51y4-MYS6NTQn9OWg5jTYYpwxn1fiKKNL5bWA37TA@mail.gmail.com> <CABcZeBNtcvATyd=jhm4GxeyY9xP5CTUp0MLUf9c-ApBFVNvWoQ@mail.gmail.com> <7b5b28f1-60d5-0979-f789-0471df33dba9@akamai.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 30 Jun 2017 09:53:29 -0700
Message-ID: <CABcZeBN0B8G3UZrLsfRakO0Vuhg=6w+aHsht4Co5pMLMWsy5-Q@mail.gmail.com>
To: Benjamin Kaduk <bkaduk@akamai.com>
Cc: "tls@ietf.org" <tls@ietf.org>, "Nygren, Erik" <nygren@akamai.com>
Content-Type: multipart/alternative; boundary="001a114dd2661d74da0553304439"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/mg5N505AD0OdkXjwR1o2zW3miJo>
Subject: Re: [TLS] Closing on 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, 30 Jun 2017 16:54:13 -0000
On Fri, Jun 30, 2017 at 9:32 AM, Benjamin Kaduk <bkaduk@akamai.com> wrote: > On 06/29/2017 03:53 PM, Eric Rescorla wrote: > > I have updated the PR to match people's comments. I would like to merge > this soon, so please get any final comments in. > > > I made a couple comments on the PR that are more appropriate for the list, > so I'll repeat them here and hopefully get replies from the broader > audience. > > > First off, I think we should MUST-level require servers to implement a > hard limit on the number of replays accepted. However, it doesn't quite > seem realistic to require "MUST use either [single-use tickets] or > [ClientHello recording]". My preference would be "MUST use either > [single-use tickets], [ClientHello recording], or equivalently strong > protection", but I don't know what level of support we have for such a > strong requirement. As an alternative, I will also put out "MUST limit > replays to at most the number of endpoints capable of accepting connections > for a given identity, and SHOULD provide even stronger replay protections, > such as [single-use tickets] or [ClientHello recording]." I think we have > general agreement that strong anti-replay as described in the document is > feasible for a single-server deployment, and this last formulation is > achievable in multi-server environments by just giving each server its own > local per-server protection. (My main reason for wanting a MUST-level hard > cap is that I worry that millions/billions of replays will have really > nasty consequences in terms of DoS and side channel issues.) > > But, this has been quite a long thread spread out over multiple > forums/email subjects, so I've also probably forgotten some of the > arguments presented against having MUST-level strong anti-replay > requirements; I'd greatly appreciate if someone could repeat them here for > everyone's consideration. > > > The pull request also has some text: > > +If the expected arrival time is in the window, then the server > +checks to see if it has recorded a matching ClientHello. It > +either aborts the handshake with an "illegal_parameter" alert > +or accepts the PSK but reject 0-RTT. If no matching ClientHello > +is found, then it accepts 0-RTT and then stores the ClientHello for > +as long as the expected_arrival_time is inside the window. > +Servers MAY also implement data stores with false positives, such as > +Bloom filters, in which case they MUST respond to apparent replay by > +rejecting 0-RTT but MUST NOT abort the handshake. > > I am not sure why we are giving servers a choice between aborting and > accepting the PSK but rejecting 0-RTT (if a matching ClientHello is found), > especially not without giving guidance as to why they might choose one or > the other. My natural inclination would be to have the expected behavior > be to abort and only fall back to the other behavior if using a scheme with > false positives, but Ekr thinks Erik Nygren was in support of just > continuing on with 1-RTT. It looks like this was > https://github.com/tlswg/tls13-spec/pull/1005#discussion_r114924733 , > where I ... took the opposite position from what I just said my "natural > inclination" was, amusingly enough. But still, why does this need to be a > choice? Rejecting 0-RTT and continuing on to 1-RTT seems like it would be > reasonable in all the cases mentioned so far. > Well, my reason for not wanting to do that is that it's a clear replay and so should be a hard failure. So, I'd be happy to mandate abort the handshake, but if we can't agree on that, I'd rather have a choice. -Ekr
- [TLS] Closing on 0-RTT Eric Rescorla
- Re: [TLS] Closing on 0-RTT Dave Garrett
- Re: [TLS] Closing on 0-RTT Colm MacCárthaigh
- Re: [TLS] Closing on 0-RTT Salz, Rich
- Re: [TLS] Closing on 0-RTT Colm MacCárthaigh
- Re: [TLS] Closing on 0-RTT Colm MacCárthaigh
- Re: [TLS] Closing on 0-RTT Ilari Liusvaara
- Re: [TLS] Closing on 0-RTT Bill Cox
- Re: [TLS] Closing on 0-RTT Victor Vasiliev
- Re: [TLS] Closing on 0-RTT Ilari Liusvaara
- Re: [TLS] Closing on 0-RTT Bill Cox
- Re: [TLS] Closing on 0-RTT Ilari Liusvaara
- Re: [TLS] Closing on 0-RTT Joseph Salowey
- Re: [TLS] Closing on 0-RTT Eric Rescorla
- Re: [TLS] Closing on 0-RTT Ilari Liusvaara
- Re: [TLS] Closing on 0-RTT Eric Rescorla
- Re: [TLS] Closing on 0-RTT Ilari Liusvaara
- Re: [TLS] Closing on 0-RTT Colm MacCárthaigh
- Re: [TLS] Closing on 0-RTT Eric Rescorla
- Re: [TLS] Closing on 0-RTT Mark Nottingham
- Re: [TLS] Closing on 0-RTT Ilari Liusvaara
- Re: [TLS] Closing on 0-RTT Eric Rescorla
- Re: [TLS] Closing on 0-RTT Eric Rescorla
- Re: [TLS] Closing on 0-RTT Benjamin Kaduk
- Re: [TLS] Closing on 0-RTT Eric Rescorla
- Re: [TLS] Closing on 0-RTT Benjamin Kaduk
- Re: [TLS] Closing on 0-RTT Erik Nygren
- Re: [TLS] Closing on 0-RTT Eric Rescorla
- Re: [TLS] Closing on 0-RTT Sean Turner
- Re: [TLS] Closing on 0-RTT Benjamin Kaduk
- Re: [TLS] Closing on 0-RTT Eric Rescorla
- Re: [TLS] Closing on 0-RTT Salz, Rich