[apenwarr]

Persistent data structures (like git) are way harder to update than non-persistent structures (like ephemeral network packets).

Hypothetical WireGuard v2 packets will simply not parse as WireGuard v1 packets; they can't be decrypted as WireGuard v1. And vice versa. It's therefore trivial to have both protocols coexist, even on the same UDP port, without any negotiation whatsoever. You simply need to discard packets that don't decrypt, which is what WireGuard already does.

It's dangerous to include a downgrade-capable negotiation in your VPN protocol. I'm glad they left that out of WireGuard.

[nickodell]

>It's therefore trivial to have both protocols coexist, even on the same UDP port, without any negotiation whatsoever. You simply need to discard packets that don't decrypt, which is what WireGuard already does.

If both ends will automatically fall back to v1, how do you prevent protocol downgrade attacks? An adversary dropping v2 packets looks exactly like the other end not supporting v2 packets.

>It's dangerous to include a downgrade-capable negotiation in your VPN protocol.

I agree. It's a hard problem to solve. But it's going to have to be solved eventually.

[apenwarr]

Why do you need automatic fallback? You simply define in the config file, for each peer, which protocol version to use. Then it's up to the config file distribution process - whatever it is that you do - to make the appropriate version settings, at the exact same time as they set up the public keys. The essential thing is that each peer has a fixed expectation of the security to use, rather than trying to negotiate it on the wire, which leads to downgrade attacks.

[Disclosure, I'm a Tailscale co-founder] ...and if you use Tailscale, it takes responsibility for the key exchange part. So we can tie protocol version settings to long-term state (eg. ratcheting up versions for each old node; not letting new nodes use old versions at all).