From: "Jason A. Donenfeld" <Jason@zx2c4.com> To: WireGuard mailing list <email@example.com> Cc: "Karolin Varner" <firstname.lastname@example.org>, noise <email@example.com>, "Ivan Labáth" <firstname.lastname@example.org> 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
next 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 \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.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).