[TLS] Closing on 0-RTT

Eric Rescorla <ekr@rtfm.com> Sun, 11 June 2017 15:18 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 36E9912441E for <tls@ietfa.amsl.com>; Sun, 11 Jun 2017 08:18:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id tgP3Fuz2cifK for <tls@ietfa.amsl.com>; Sun, 11 Jun 2017 08:18:46 -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 98F37127011 for <tls@ietf.org>; Sun, 11 Jun 2017 08:18:44 -0700 (PDT)
Received: by mail-yw0-x22f.google.com with SMTP id 63so30457472ywr.0 for <tls@ietf.org>; Sun, 11 Jun 2017 08:18:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=6SWnNl436DSyxubacVFKb+zPzE9NFdRwUSRCjo4nEpQ=; b=rspS9rwWtgZYZNhhLalvpvGekp3VP6Al/OVQvZy0JIO68qtcX/NIoBRuCKtC8qQ7sH H6mxuKRBX0OAox+/CH8X9eY63E5n1Mpv5PDct7UupVqaVYKid54bsKrzMYgIjXKOQSm5 rWEC7E1WAXCavBFvHCrPDvPgd7IuLZURrCbwMYbbgSaibilbVQdNYqMqDe6cV2Rkrmli 9qjGmMmrdJE9FbBX+dv/YBRT31IXPRrZPom01I17Y5Ch3j5mLJyW849jecdA+QStJh7l ZoZh55rreAt64EWW34h2zTcnJt6F3j4CAwSR6biV9JXFixFG4g7z+wukm+EZfiHRGYRU V9/w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=6SWnNl436DSyxubacVFKb+zPzE9NFdRwUSRCjo4nEpQ=; b=AsIbbRb66I5sCkz2gdXCv2tjmqRI6AB6xBDAb1hw1AoGL2X8zFNX0GZ+ubFck7liaB chu8mJf+WYv7p6WHmtr4fPu73OZA2U+wkVgMUQ1pQgVUCXPcDNr4ntGwpsRAzN8Gv/aK 79yvo7LY7vcRHIg3aAq8ZBn9EEN8FMxbiRHH3Akx4nj3IQ3pkOOEt9BU+Rlj6nin4v5w nd1COaToa6WTsAdN6sPQpfsZK1qv30jIHn5i8nS0RyYIWyacLO242mf0cxuscQPd3nFD 6z0Lt2AuWx7/8FFrYrCx4TTemTe9Gw3rSYK6vCB9AYA1Ur4pVsXmc9Aecrn1FjpInR6k 3Bjw==
X-Gm-Message-State: AODbwcDd+EsX7ZZGnSljN3hwg1BJi3MpIWeTWAOGLzRevraT00uNom63 n9zFtHZGmRodTE41gsCYV+e70DjIFJgFyPdX/g==
X-Received: by with SMTP id j9mr21168680ywg.283.1497194323557; Sun, 11 Jun 2017 08:18:43 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sun, 11 Jun 2017 08:18:03 -0700 (PDT)
From: Eric Rescorla <ekr@rtfm.com>
Date: Sun, 11 Jun 2017 16:18:03 +0100
Message-ID: <CABcZeBNLo51y4-MYS6NTQn9OWg5jTYYpwxn1fiKKNL5bWA37TA@mail.gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c0928d4d0e4f50551b0b740"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/HUUpDl7KUOGhcY_W_IC2vWRAot0>
Subject: [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: Sun, 11 Jun 2017 15:18:48 -0000

Hi folks,

We've had a phenomenal amount of discussion around 0-RTT anti-replay,
and based on my recent summary e-mails I think we generally agree
about the technical facts, so it's time to finalize the PR and land it
in the specification.

Here's what I propose to do:

- Describe the attacks that Colm described.

- Distinguish between replay and retransmission

- Mandate (SHOULD-level) that servers do some sort of bounded
  (at-most-N times) anti-replay mechanism and emphasize that
  implementations that forbid replays entirely (only allowing
  retransmission) are superior.

- Describe the stateless mechanism as a recommended behavior but not
  as a substitute for the other mechanisms. As Martin Thomson has
  pointed out, it's a nice pre-filter for either of these other

- Clarify the behavior you need to get PFS.

- Require (MUST) that clients only send and servers only accept "safe"
  requests in 0-RTT, but allow implementations to determine what is

Note: there's been a lot of debate about exactly where this stuff
should go in the document and how it should be phrased.  I think these
are editorial questions and so largely my discretion.

Here's what I do not intend to do.

- Mandate (MUST-level) any anti-replay mechanism. I do not believe
  there is any WG consensus for this.

- Design a mechanism to allow the server to tell the client that it
  either (a) enforces strong anti-replay or (b) deletes PSKs after
  first use. Either of these seem like OK ideas, but they can be added
  to NST as extensions at some future time, and I haven't seen a lot
  of evidence that existing clients would consume these.

I recognize that nobody will be entirely happy with this, but I
believe it most closely represents consensus. Assuming the chairs
agree, I'd like to suggest a brief period of discussion on this
proposal, followed by a consensus call, and then I'll generate a PR
that enacts it. People will still have time to review that, but in
order to avoid an endless round of dicussion, the idea will be able to
review it for conformance to these principles, not to re-litigate