Re: [TLS] Closing on 0-RTT

[Eric Rescorla <[e-mail]>]

I have updated the PR to match people's comments. I would like to merge
this soon, so please get any final comments in.

-Ekr


On Sun, Jun 11, 2017 at 8:18 AM, Eric Rescorla <[e-mail]> wrote:

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