> 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
