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