wireguard.lists.zx2c4.com archive mirror
 help / color / mirror / Atom feed
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

  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 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 \
    --subject='Re: another thread on montonic counter alternatives' \
    /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

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).