On Fri, May 05, 2017 at 09:28:07AM -0700, Colm MacCárthaigh wrote: > I wanted to start a separate thread on this, just to make some small > aspects of replay mitigating clear, because I'd like to make a case for TLS > providing a single-stream, which is what people seem to be doing anyway.
<Snip a long mail> Couple points: - AFAIK, the 10 second or so figure in existing spec is a slop margin, which means the replay window would be 20 seconds, not 10. - The size of the window depends on clock error margin and transport delay margin. At 1s/day clock error margin, you need 14 second window just from clock error. - It is not just low-power devices with really bad clocks. I have seen 20s per day(!) clock drift on high-power device that doesn't sleep. - So basically, the size of window is tradeoff with number of devices. - That automatic wait on 0-RTT failure seems just the kind of feature that gets disabled. Furthermore, 10 second idle on connection is going to trigger quite a bit of connection timeouts. - There seems to be no consideration how this interacts with 0-RTT exporters (probably applications that accept 0-RTT will then use 0-RTT exporters for the entiere connection, and those exporters have seriously weaker properties). -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
