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
