Re: [TLS] Closing on 0-RTT
Eric Rescorla <ekr@rtfm.com> Fri, 30 June 2017 17:24 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 2A599131454 for <tls@ietfa.amsl.com>; Fri, 30 Jun 2017 10:24:02 -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 ftTQvDNv2MH8 for <tls@ietfa.amsl.com>; Fri, 30 Jun 2017 10:23:59 -0700 (PDT)
Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (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 67FD8131448 for <tls@ietf.org>; Fri, 30 Jun 2017 10:23:59 -0700 (PDT)
Received: by mail-yw0-x231.google.com with SMTP id a12so3676312ywh.3 for <tls@ietf.org>; Fri, 30 Jun 2017 10:23:59 -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=7IqWWB390clHfGdCXJweUd36+nlqNAZ4PiMZEQEevIw=; b=OZ6hvrXqxRIpBF2DKvdAqy7RXzgmXO19JL+ZmYla/ADmjKABATaQKIQIr11mOG3ZVY LBRCHIh34tLEMF9dbEklIWPnYKyJF+z+hCt5zQDlvEBAk53ID/ZRUUnq6ftjSdCzuSdg 9WywuexUCKUgnwt2RKHWjcZrdVAxdVdX6j7TGydkUQFzCGpjfzkPfccU3e+IE1D7PB1v mtST0KIMQTeWolOcU1y/FfyiRM+rZM+JRcGSKyV34C9HqMYswiUcXRe2HD5JbFH2ix1x 9SBGbnfpZGo9RB4eTIIZZKET/MTuCsaguqyP+UY7ErPOL6SkOHmW9g4g+fklCMhTOMzV 9dzA==
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=7IqWWB390clHfGdCXJweUd36+nlqNAZ4PiMZEQEevIw=; b=sUleb8DWo3RxiZ8YRHnWUMW5AjZsGCwoEZLWi5wByNzBib2X3hpmrXP/6iJrcn9s2o gK6C5GWRG+umtIdhZTMZ0/g44CMmhJqanLAEnrm4kcNE0JxGjTaYpgf3ZyuXfIvO7l/s QdJRseS9AeLe8a6w/ArtvEVs/NBE0gpgzlJ5x1aFD6zQvgKbpPa8EDBbsZiBQ4e+3hvS 4GQTBXGeByBcYDUMYX66DcaqoKMwQidcZTs4ayxHXFcvzKptj/TmiFSToOC3lKSusFnY +L6zoKW14DlhuxI6JgzaSiGSvJUAgM8X2l1fBkwbOsWPuOb0MbL/LAOy6Df8Yoq/0naW +ePA==
X-Gm-Message-State: AKS2vOwz3p2p5dwFYsCZcM+CrFPtlcIk93o951gvLj8R3gN4R1mXUdHN VUVAHGMQArkZKjEO+9LMqtoUkKT36sa8NBs=
X-Received: by 10.129.109.206 with SMTP id i197mr10596021ywc.24.1498843438653; Fri, 30 Jun 2017 10:23:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.13.215.9 with HTTP; Fri, 30 Jun 2017 10:23:18 -0700 (PDT)
In-Reply-To: <CAKC-DJiEy75Hx1fMRm6_E_rptuRNRTZBZ+SQmR6XQg8+sbshqw@mail.gmail.com>
References: <CABcZeBNLo51y4-MYS6NTQn9OWg5jTYYpwxn1fiKKNL5bWA37TA@mail.gmail.com> <CABcZeBNtcvATyd=jhm4GxeyY9xP5CTUp0MLUf9c-ApBFVNvWoQ@mail.gmail.com> <7b5b28f1-60d5-0979-f789-0471df33dba9@akamai.com> <CABcZeBN0B8G3UZrLsfRakO0Vuhg=6w+aHsht4Co5pMLMWsy5-Q@mail.gmail.com> <CAKC-DJiEy75Hx1fMRm6_E_rptuRNRTZBZ+SQmR6XQg8+sbshqw@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 30 Jun 2017 10:23:18 -0700
Message-ID: <CABcZeBOq5qeFqXYPZd-JM98dJfMHVSoMfhd9PAq_ADb3JimiQw@mail.gmail.com>
To: Erik Nygren <nygren@akamai.com>
Cc: Benjamin Kaduk <bkaduk@akamai.com>, "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="001a114dd266bc56ad055330ae29"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/-ftfjzdhBZzBoCaNWsTjj11bJJM>
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 17:24:02 -0000
On Fri, Jun 30, 2017 at 10:19 AM, Erik Nygren <nygren@akamai.com> wrote: > On Fri, Jun 30, 2017 at 12:53 PM, Eric Rescorla <ekr@rtfm.com> wrote: > >> >> 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. >> > > Are there scenarios where the duplication might be accidental rather than > a malicious attack? > For example, one might see cases where combining 0RTT with TFO and network > packet > duplication could result in two initial 0RTT flights. One could also see > "TCP accelerator" > middleboxes doing similar things where the first flight gets replayed. > Sure, and this is a good reason to hard fail because it helps us find stuff like that. In both of these cases, only one will actually successfully establish a TLS > connection > and move forwards, but if the successful one is the one that is aborted > then > the connection will fail. > Sure, though of course clients can also retry. -Ekr > If 0RTT is rejected and both are allowed to proceed, > then the bogus accidental replay will be dropped and the legit connection > will succeed. > > Erik > > > > >
- [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