> On May 2, 2017, at 8:28 PM, Colm MacCárthaigh <c...@allcosts.net> wrote:
>
> This whole problem of needing client-side clocks, and having to obfuscate an
> age, goes away if we remove the ticket age entirely.
>
> Hopefully the security review makes a strong case that the age is fairly
> useless from a security point of view. Even with the age, an attacker can
> still generate millions to billions of replays. Even with very conservative
> numbers, e.g. to just one host, the attacker can still certainly generate
> tens of thousands of replays within the permitted window. Better to require
> servers to reject duplicates (when used with Zero-RTT), and leave it at that.
Some choices are driven by practical engineering considerations.
The ticket lifetime is likely to be considerably longer than the
replay clock window. The server should indeed reject replays,
but if it is able to flush the replay cache faster, it may be able
to handle that job a lot more efficiently under load.
What is a likely ticket lifetime for a server that supports 0-RTT
(let's assume an HTTP server)? How wide a replay clock window is
likely reasonable (to allow for RTT and TCP retransmission delays)?
If the two are approximately the same, then just rejecting duplicates
and expired tickets is enough. If the ticket lifetime is 10x or 100x
larger, it may make sense to be able to limit the lifetime of replay
cache entries to the smaller TCP skew.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
