On 30 March 2016 at 11:30, Colm MacCárthaigh <c...@allcosts.net> wrote: > * How is the elapsed time on the wire authenticated? can't an attacker > modify it and replay?
It is authenticated by virtue of being part of the session transcript. It will be authenticated by the Finished message included by the client, by the key derivation, and ultimately by the remainder of the 1RTT handshake. > * Should the difference really be 1RTT, or 1/2 RTT (well, really "TT" I > guess) ? No. The server records the time that it generates the ticket. Then that ticket travels to the client (1/2 RTT). At that point the counter starts. Then, on resumption, the client stops the clock and sends the message to the server (1/2 RTT). > * Clock drift; especially on clients, seems like a real problem here - how > tight would realistic tolerances be? Clock drift over this time frame is a small problem, but one that can be managed by having a small allowance for drift. In my experience, drift is likely to be small enough that errors in RTT measurement are more likely to dominate [47][48]. What is more likely to be a problem is time corrections during that time (via NTP for instance). In any case, these sorts of errors fail soft. You just lose 0-RTT. [47] I have seen drift in the order of seconds per day, but that is rare. Those users will find lower rates of 0-RTT acceptance, or 0-RTT will only work over shorter periods. That's not great, but we can't always win. Most clock errors are simple "I didn't even setup NTP" sort of problems. [48] Users with high round trip variability will suffer too. That's very common in developing countries, and on wireless networks. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
