Good evening, I can see this has been copiously discussed…
On 8/9/21 12:33 AM, Jason A. Donenfeld wrote: > Angle 2 presents some interesting possibilities. An adversary who sets > somebody's time backwards can prevent them from connecting until their > time is set right again. Adversaries who set somebody's time forward, > say, to the maximum TAI64N value, and then subsequently have an > initiator send an initiation message, can then render that initiator's > static private key forever useless, since that future timestamp can > always be replayed, and will always set the responder's greatest-yet > value to that maximum. So, if your NTP is hijacked, your key is > forever DoS'd. In my view this presents a major problem. I don't have data on this, but I think this is a common setup. Mine was vulnerable and if you didn't take care to prevent this yours is probably too. At the very least there should be a bold, red warning on the webpage "do not use WG with NTP". > Other clever ideas? 0) Just send the value of tsmax to the peer? This basically surmounts to falling back to fully interactive but is a minimal change? 1) Pick a random time stamp/a time stamp based on the peers `MAC(cookie_secret, IP | Port)` and accept that for a single time only. This also basically surmounts to an interactive handshake with minimal changes. Is changing the protocol an option? Two options for that: 2) Fall back to an interactive handshake using cookies. Define a protocol version two, mandate that in V2 the cookie must be mixed into the handshake hash. Assign a cookie in case of timestamp failure. 3) Use a stateless responder; forego the timestamp entirely. Instead of storing the handshake state (ck, h, eskr) locally, they could be encrypted with a random key and included in the second message. This way, there is no responder state an attacker could interrupt. 2) is 1-RTT in the normal case and 2-RTT with the attack agains the counter. 3) is always 1-RTT and always interactive but requires a response for replayed old handshakes. Jason pointed out, that it would be preferable to use a Noise-XK handshake which is a standard fully-interactive handshake but 1.5-RTT. I was assuming 1-RTT-ness was a necessity. Of course, coming up with a new handshake is…generally foolish and even though both my proposal technially fit into the noise-IK pattern, noise-XK certainly is more trustworthy. Noise XK could also be used as a fallback only, but this would considerably increase complexity. As far as mitigations go: a) Do not drop handshake state after three minutes, just ratchet the key `MixKey(empty)` so the attack can not disrupt active sessions. b) Jason's angle 4 but with a flag. A command line switch "interpret counter as timestamp and reject timestamps off by more than 20m". Best, Karolin
