From: Karolin Varner <karo@cupdev.net>
To: wireguard@lists.zx2c4.com
Cc: noise@moderncrypto.org, labo@labo.rs
Subject: Re: another thread on montonic counter alternatives
Date: Mon, 9 Aug 2021 01:18:59 +0200 [thread overview]
Message-ID: <6cd87006-902a-3411-4928-67ec5d1f77e2@cupdev.net> (raw)
In-Reply-To: <CAHmME9q_9frZ+EQ4_sq_aEoFn3sU01LcW25RysWj0mas4po47Q@mail.gmail.com>
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
next prev parent reply other threads:[~2021-08-09 0:04 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-08 22:33 another thread on montonic counter alternatives Jason A. Donenfeld
2021-08-08 23:18 ` Karolin Varner [this message]
2021-08-10 0:09 ` Trevor Perrin
2021-08-10 7:53 ` Karolin Varner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6cd87006-902a-3411-4928-67ec5d1f77e2@cupdev.net \
--to=karo@cupdev.net \
--cc=labo@labo.rs \
--cc=noise@moderncrypto.org \
--cc=wireguard@lists.zx2c4.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).