On Tue, May 2, 2017 at 5:51 PM, Viktor Dukhovni <ietf-d...@dukhovni.org> wrote:
> .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. > Good point! It's also common for caches to implement LRU, where a shorter lifetime is better. What is a likely ticket lifetime for a server that supports 0-RTT > (let's assume an HTTP server)? I'm going to guess that providers will set it as high as they can ... every little helps. So 7 days. > How wide a replay clock window is likely reasonable (to allow for RTT and > TCP retransmission delays)? > I think we have to assume that a replay attempt could come at any time. A time based mitigation doesn't work. -- Colm -- Colm
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
