Development discussion of WireGuard
 help / color / mirror / Atom feed
From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: Reid Rankin <reidrankin@gmail.com>
Cc: "WireGuard mailing list" <wireguard@lists.zx2c4.com>,
	"Toke Høiland-Jørgensen" <toke@toke.dk>,
	"Roman Mamedov" <rm@romanrm.net>,
	ch@ntrv.dk, "Arti Zirk" <arti.zirk@gmail.com>
Subject: Re: Standardized IPv6 ULA from PublicKey
Date: Mon, 29 Jun 2020 19:24:31 -0600	[thread overview]
Message-ID: <CAHmME9prQFruLSsJ-jW1yF4ohfOkiqWR3Jjax=HDrLiQ5Dy_MQ@mail.gmail.com> (raw)
In-Reply-To: <CAMaqUZ1TkemV7Ocvx+VzHUbOJeEx_L4tVTPLzbzS4hzBu7TXaQ@mail.gmail.com>

On Mon, Jun 29, 2020 at 1:59 PM Reid Rankin <reidrankin@gmail.com> wrote:
> Well, it looks like you've discovered the method behind my madness!
> Specifically, while a handshake *initiator* must know the public key
> of the responder it's trying to talk to, the *responder* doesn't need
> to know anything about the initiator ahead of time -- because the
> initiator's public key is right there in the handshake.

Fun fact: initial versions of WireGuard from years ago weren't like
this. We wound up redoing some crypto and coming up with the `_psk2`
variant for this purpose. I'm glad it's useful. I'm interested to
learn: what are you doing this for? Got any code online?

> In my usecase,
> I examine incoming handshake requests in a userspace daemon via
> nfqueue. The daemon knows the interface private key, so it can also
> see the initiator's public key, and if it's a new peer the daemon adds
> it via `wg set` -- with only the calculated LLA in the `AllowedIPs`
> list -- before releasing the handshake request for delivery. The
> newly-minted peer can then send a certificate via TFTP (a very simple,
> DoS-resistant protocol) to the responder's LLA, which convinces the
> responder to add additional stuff to the initiator's `AllowedIPs`
> list. Because this bootstrap process occurs within the tunnel,
> integrity and confidentiality protection are already assured -- and
> WireGuard is already ensuring that the node with the initiator's LLA
> possesses the initiator's private key.

This sounds like a motivation for doing the LLv6 generation inside of
your daemon, not inside of the kernel, right? In that case, your
design must already take into account a malicious peer finding public
key collisions after hashing. Perhaps you have some PRF situation? Or
something else? Either way, this doesn't sound like something for
core-wireguard, but a nice and novel thing you're building on top,
sort of like wg-dynamic, which can happily exist in userspace, where
the security of your design can be validated as one unit.

Jason

  reply	other threads:[~2020-06-30  1:25 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-04 16:52 Lonnie Abelbeck
2017-12-04 17:14 ` Aaron Jones
2017-12-05  2:53 ` Luis Ressel
2017-12-05  3:31   ` Jason A. Donenfeld
2020-06-24 15:37     ` Florian Klink
2020-06-24 17:08       ` Chriztoffer Hansen
2020-06-24 17:30         ` JuniorJPDJ
2020-06-27 21:43         ` Reid Rankin
2020-06-28 10:15           ` Arti Zirk
2020-06-28 15:19             ` Derrick Lyndon Pallas
2020-06-29 10:22           ` Toke Høiland-Jørgensen
2020-06-29 10:31             ` Roman Mamedov
2020-06-29 10:52               ` Justin Kilpatrick
2020-06-29 11:03               ` Toke Høiland-Jørgensen
2020-06-29 11:38                 ` Roman Mamedov
2020-06-29 12:15                   ` Toke Høiland-Jørgensen
2020-06-29 17:01                     ` Arti Zirk
2020-06-29 18:01                       ` Jason A. Donenfeld
2020-06-29 19:58                         ` Reid Rankin
2020-06-30  1:24                           ` Jason A. Donenfeld [this message]
2020-06-30  8:01                             ` Reid Rankin
2020-06-29 18:49                     ` Luiz Angelo Daros de Luca

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='CAHmME9prQFruLSsJ-jW1yF4ohfOkiqWR3Jjax=HDrLiQ5Dy_MQ@mail.gmail.com' \
    --to=jason@zx2c4.com \
    --cc=arti.zirk@gmail.com \
    --cc=ch@ntrv.dk \
    --cc=reidrankin@gmail.com \
    --cc=rm@romanrm.net \
    --cc=toke@toke.dk \
    --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).