On Thu, Jan 11, 2024, at 18:38, Christian Huitema wrote: > If an implementation does not want to deal with the extra complexity, > then having a way to plug in some extra code for a specific scenario > makes sense...
My point was that the handling does not need to be complex, only the tolerance for time variation needs to be. Tolerance is driven by two things: RTT and clock variations. But - critically - that tolerance needs to be uniformly managed across the entire set of clients. If you have clients that have very tight variance on timing, you can use a narrow window, but you risk excluding those with high variance. If you want to allow for high variance, you spend more in doing so, largely by having to track more 0-RTT attempts over a wider window of time. You can't selectively change that tolerance. Otherwise, an attacker looking to exploit replay can choose whichever per-client reaction suits them best. I'm assuming this is a DoS attack, I can't see how you would exploit this to mount a replay, though you might choose an option with false negatives on replay detection ... you shouldn't. All of the distributed systems challenges that apply shouldn't be affected by long RTT unless you start increasing the distance between nodes that share 0-RTT state in ways that could be exploitable (note: do not do this, sharing state between collocated nodes is already risky enough). _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
