wireguard.lists.zx2c4.com archive mirror
 help / color / mirror / Atom feed
From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: WireGuard mailing list <wireguard@lists.zx2c4.com>
Cc: "Karolin Varner" <karo@cupdev.net>,
	noise <noise@moderncrypto.org>, "Ivan Labáth" <labo@labo.rs>
Subject: another thread on montonic counter alternatives
Date: Mon, 9 Aug 2021 00:33:13 +0200	[thread overview]
Message-ID: <CAHmME9q_9frZ+EQ4_sq_aEoFn3sU01LcW25RysWj0mas4po47Q@mail.gmail.com> (raw)

Hi folks,

We've had this discussion a few times in various forms, but it's come
up again recently, with Karolin Varner (CC'd) emailing me with some
fresh enthusiasm about the problem space, so I thought this might be
something worth discussing again, perhaps this time with some input
from the Noise mailing list.

NoiseIK is 1-RTT, so WireGuard sticks a timestamp in the first message
to prevent replay attacks. Responders reject packets with timestamps
that are larger than the last one received. If a responder reboots,
there's subsequently no session to disrupt with a replay anyway, so
it's not an issue. Generally this works well, provided initiators have
a reliable monotonic counter. Generally timestamps are considered
reliable-enough monotonic counters. Issues with this begin from two
angles:

Angle 1) Embedded devices without a battery powered RTC that want to
use WireGuard to bootstrap have a chicken & egg problem.
Angle 2) Initiators that are using the old, crusty, and insecure NTP
protocol can have their time hijacked.

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.

We've talked about a few solutions before to this. They all have
various pitfalls.

Idea 0) Insist people don't use NTP but rather some authenticated
alternative. Insist people have battery-powered RTCs.

Idea 1) Store a monotonic counter on disk, and just increment it by 1,
or even some random value bounded far below the limit, on each
handshake. The downside is this relies on storage that doesn't wear
out and is always available.

Idea 2) For a given system boot, store in memory the time of the first
handshake, and then increment that timestamp by 1 on each handshake.
The problem is figuring out when to sample that initial golden
timestamp. And it doesn't actually solve Angle 2, because that initial
golden timestamp still might wind up NTP sync'd at some point.

Idea 3) Insist people who must use NTP disable large jumps. This has
the same issue as Idea 2, in that the bootstrapping timestamp is still
an issue.

Idea 4) Require the responder to also have a synchronized clock and
reject handshakes that are too far into the future. This might
alleviate Angle 2 to a large degree but it causes big issues for Angle
1, potentially.

Other clever ideas?

Jason

             reply	other threads:[~2021-08-08 22:35 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-08 22:33 Jason A. Donenfeld [this message]
2021-08-08 23:18 ` Karolin Varner
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=CAHmME9q_9frZ+EQ4_sq_aEoFn3sU01LcW25RysWj0mas4po47Q@mail.gmail.com \
    --to=jason@zx2c4.com \
    --cc=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).