Subject: [TLS] Closing on 0-RTT
From: Eric Rescorla <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Sun, 11 Jun 2017 16:18:03 +0100
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>

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
  mechanisms.

- 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
  safe.

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
these.

-Ekr