Breaking user space might not be popular with users, but it makes sense for security. Besides, anyone could build protocol negotiation on top of WireGuard v1/v2 if they wanted to.

I'm not a kernel dev, but WireGuard v2 will probably be implemented as a separate kernel module so they can coexist. It makes sense to do it that way since they're practically entirely separate protocols.

> Besides, anyone could build protocol negotiation on top of WireGuard v1/v2 if they wanted to

This is the thing I'm afraid of. It's noble to have a lean protocol but leaving things like this to be externalized is just going to create a mess of incompatible middleware when there could have been a "blessed" solution.

If people want that, there are already tons of other VPN options. Donenfeld didn't leave it to third parties, he doesn't want cipher negotiation at all. Other people can do whatever they want and the base project remains untainted. I personally don't really see the difference between having negotiation built in vs. the community building their own solution, the community has just as capable developers. OSS is projects building on other projects and WireGuard fully embraces that to provide a package that does only what it has to, but does it really well.

I’m not sure that coexistence works without a version number going over the wire.

Sure it does. They are two separate packages, run on two separate network ports and completely incompatible. Just pretend that WireGuard v2 is unrelated to WireGuard. "OpenVPN and WireGuard coexistence doesn't work without a version number going over the wire" would be an absurd statement and the same applies to WireGuard and WireGuard's descendants.

I suppose you’re right. It is left to the user to not try to connect v1 to v2. Not sure what happens if on Tuesday morning I connect my v1 client to what was on Monday night a v1 server.

That said, I admire opinionated design.

The two versions can run in parallel so you will never be in a situation where the sysadmin is forced to take down the v1 server to set up a v2 server. It's the sysadmins responsibility not to put users in that situation. Users might try to use the wrong version at first, but there's no reason for an admin to break the working VPN before the transition is complete.

Speaking vaguely of this topic, the ciphersuite of WireGuard:

How much trouble do you think it would be for a CPU designer to include a ChaCha20 accelerator or some sort of round/double-round/quarter-round³ primitive? It seems like the cost would be an order of magnitude lower than something like an AES accelerator, and way easier to validate.

I keep wondering if it's going to be this year, the next, or the one after that; but ChaCha20† is getting really popular, so I can imagine something like this could be very valuable, especially on a chip for an infrastructure provider like CloudFlare‡ , or any VPN megacompany.

† which may have more rounds than necessary, good reason not to do all 20 in one primitive if that costs latency/throughput

‡ who use ChaCha-based TLS for devices with poor, nonexistent, or misconfigured AES accel.

³ this relatively straightforward operation https://github.com/jedisct1/libsodium/blob/master/src/libsod...