On Mon, Jun 29, 2020 at 1:59 PM Reid Rankin <[email protected]> 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
