Standardized IPv6 ULA from PublicKey

[Reid Rankin]

> 2. There is very little practical utility. In WireGuard, both sides
> must _already_ preshare their public keys, and there's no way around
> this.

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. 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.

Now, I'm not recommending this specific scheme generally, but it goes
to show that there is indeed a benefit to calculating an LLA via a
hash -- it allows you to move an out-of-band authentication ceremony
in-band. Maybe you're not using my fancy nfqueue setup to pull out
public keys from handshakes -- you could just have a web server with a
POST handler that takes unknown public keys and adds them as peers.
You're not trusting anything by doing this if you're using a hashed
LLA, and then you could proceed to chat inside the tunnel to run
whatever authentication scheme you'd like. But if you're taking both a
public key and an arbitrary LLA as input, you're going to have to
trust the assertion that that specific public key should be assigned
that specific address. To do that, you'll need to verify both that the
owner of the public key indeed wants that LLA (what if the request was
forged?) and that the owner of the key is authorized to use that LLA
(what if they're trying to steal or squat on someone else's address?),
and you'll have to do both of those things out-of-band -- because
until you settle on addressing you can't even talk to each other
inside the tunnel.

Anyhow, my point is that pre-sharing public keys might be easy, but
sharing *relationships* between public keys and addresses is a whole
different ball of wax, requiring at least an integrity-protected
transport -- which would be a shame to have to do out-of-band, since
we've already got one of those.

--Reid