Development discussion of WireGuard
 help / color / mirror / Atom feed
From: Axel Neumann <neumann@cgws.de>
To: wireguard@lists.zx2c4.com
Subject: Re: WG: Need for HW-clock independent timestamps
Date: Mon, 21 May 2018 12:07:38 +0200	[thread overview]
Message-ID: <403fa228-40e5-cbe4-4135-15b71cf76553@cgws.de> (raw)
In-Reply-To: <c1e04862-162f-eff9-7884-467f672608e2@cgws.de>

Hello,

With regards to the subject, ...to discuss the demand and identify
solutions for a "HW-clock INDEPENDENT WG solution", I've seen
essentially three different suggestions so fare:

a) Buy and connect a HW clock.
IMO: Often difficult considering available HW, budget, and skills.

b) Rely on the (HW) clock of somebody else,
considering network time protocols (e.g. NTP, RFC867, RFC868,...) and
related (security) implications (such as new dependencies on remote
services, IP or DNS spoofing, firewall settings, boot-service order,
...). Some experience [1] suggest to go for a).
IMO: A concrete best practice would be good here but would likely
overshoot the complexity and other-systems-dependencies of WG by magnitudes.

c) Modify WG to use (time-independent) counter-based values to prevent
replay-attacks.
Paul [2] gave a pretty nice overview of the yet identified advantages
and implications, suggesting that it requires only few and simple code
changes, introduces no security drawbacks, could be fully compatible
with existing protocol and implementations, and makes HWC or NTP
entirely superfluous. As discussed earlier [3] it can be achieved with
essentially one file-system write operation each boot.

There have been many good comments for a) and b). Still, I'd be happy to
elaborate the case of c), or a maybe a fourth idea, a bit further...
What technical concerns do you see with c) or what suggestions would you
make to somebody working out a patch?

[1] https://lists.zx2c4.com/pipermail/wireguard/2018-May/002832.html
[2] https://lists.zx2c4.com/pipermail/wireguard/2018-May/002875.html
[3] https://lists.zx2c4.com/pipermail/wireguard/2018-May/002865.html

/axel

  parent reply	other threads:[~2018-05-21 10:06 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-11 22:07 Axel Neumann
2018-05-11 22:45 ` Kalin KOZHUHAROV
2018-05-12  0:05   ` Glen Bojsza
2018-05-12 19:29   ` Axel Neumann
2018-05-12 19:41     ` Aaron Jones
2018-05-15 20:21       ` Devan Carpenter
2018-05-15 20:49         ` Kalin KOZHUHAROV
2018-05-16  7:10           ` Matthias Urlichs
2018-05-16 19:32           ` Axel Neumann
2018-05-16 20:32             ` Steve Gilberd
2018-05-17  3:40               ` Paul
2018-05-17  5:03                 ` Roman Mamedov
2018-05-17  5:53                   ` Matthias Urlichs
2018-05-17  7:07                     ` Axel Neumann
2018-05-17  8:28                       ` Matthias Urlichs
2018-05-16 20:35             ` Kalin KOZHUHAROV
2018-05-12 22:10     ` Toke Høiland-Jørgensen
2018-05-12 23:05     ` Reuben Martin
2018-05-13  6:11     ` Matthias Urlichs
2018-05-13 12:37       ` Toke Høiland-Jørgensen
2018-05-16  7:01         ` Axel Neumann
2018-05-16  9:38           ` Toke Høiland-Jørgensen
2018-05-16 11:08             ` Matthias Urlichs
2018-05-16 11:12             ` Axel Neumann
2018-05-13 14:21   ` Wang Jian
2018-05-21 10:07 ` Axel Neumann [this message]
2018-05-21 11:22   ` WG: " Reto Brunner
2018-05-21 11:52     ` Axel Neumann
2018-05-21 12:31       ` Axel Neumann
2018-05-21 12:35       ` Reto Brunner
2018-05-21 13:53         ` Matthias Urlichs
2018-05-21 14:56           ` Bruno Wolff III
2018-05-21 15:34             ` Matthias Urlichs
2018-05-22 20:25               ` Ivan Labáth
2018-05-23  2:51                 ` Matthias Urlichs
2019-02-04 14:56                 ` Jason A. Donenfeld
2019-02-23  4:00                   ` Axel Neumann
2019-02-23 12:35                     ` Ivan Labáth
     [not found] <1522499692.6109802.1526903933505.ref@mail.yahoo.com>
2018-05-21 11:58 ` reiner otto

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=403fa228-40e5-cbe4-4135-15b71cf76553@cgws.de \
    --to=neumann@cgws.de \
    --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).