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...@rtfm.com> 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 > > > > > > > > > > > > > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
