Encrypted extensions for client #449
Conversation
| Implementations SHOULD determine the security parameters for the | ||
| 1-RTT phase of the connection entirely before processing the EncryptedExtensions | ||
| and Finished, using those values solely to determine whether to | ||
| accept or reject the "early_data" extension. |
There was a problem hiding this comment.
It's not the extension that is being accepted or rejected, it's the 0-RTT data.
ekr
force-pushed
the
encrypted_extensions_for_client
branch
from
121d545
to
e64c039
Compare
| propagation delays are most likely causes of a mismatch in legitimate | ||
| values for elapsed time. Both the NewSessionTicket and ClientHello | ||
| messages might be retransmitted and therefore delayed, which might be | ||
| hidden by TCP. |
There was a problem hiding this comment.
The client could also have since moved to another network. Or perhaps got load-balanced to a different server. Or maybe I got the ticket at 4am when no one was awake and now it's noon and the network's busier.
I'm not sure how useful it is to pin down all the sources of error and recommend that servers SHOULD measure the RTT and put it in NewSessionTicket. I think more realistic is that servers will pick some vaguely reasonable amount of slop and use that.
I also suspect the difference between "an attacker can replay this for 5 seconds" and "an attacker can replay this for 1 minute" isn't much and so keeping the clock tight isn't that valuable. If you're online-ish, you can get a lot of replays in anyway. I'd probably buy "an attacker can replay this for 1 minute" vs. "an attacker can replay this for however long this ticket key is alive" is meaningful since that's now offline-ish.
WIP, not ready to land. @martinthomson PTAL