On Tue, May 02, 2017 at 11:27:04PM -0400, Viktor Dukhovni wrote: > > On May 2, 2017, at 9:45 PM, Colm MacCárthaigh <[email protected]> wrote: > > I think we have to assume that a replay attempt could come at any time. > > A time based mitigation doesn't work. > > A time-based mitigation does not remove the need for an anti-replay > cache (where a service protocol, supports 0-RTT, but is not idempotent).
Bingo. There's no need for a replay cache for the 0 payload if it represents an idempotent operation. As long as the server can fall back on a full handshake, all is good. > What I am saying, is that a time-based counter-measure can substantially > reduce the size of the required cache, because out-of-window replays > are rejected. That replay window can be a narrow window around the time > the ticket is first (and never again legitimately) used, rather than the > much larger ticket validity interval. I don't believe replay cache size is that big a deal (though it's not nothing). The hard thing is concurrency. > I agree with Nico that additive obfuscation feels like a hack, but am > willing to accept this as somewhat "natural" within the design tradition > of TLS. That is... a ringing endorsement of he obfuscation thing! :) Nico -- _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
