Re: Standardized IPv6 ULA from PublicKey

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