6 ms·

Yes, it seemed to me that Donenfeld was pretty opinionated about 'updating breaks compatibility'. Donenfeld is the anti-Torvalds: we will break user space. This

Yes, it seemed to me that Donenfeld was pretty opinionated about 'updating breaks compatibility'. Donenfeld is the anti-Torvalds: we will break user space. This is the closest quote I could find. If holes are found in the underlying primitives, all endpoints will be required to update. Unlike IP packets, struct message_header doesn't even have a version number. I suppose type could be used for that since it's 32b. An interesting question is how will this play out with Wireguard going into the Linux kernel itself.

XelNika 7y ago
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.
- CalChris 7y ago
  I’m not sure that coexistence works without a version number going over the wire.
  - XelNika 7y ago
    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.
    - CalChris 7y ago
      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.
      - XelNika 7y ago
        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.
  - microcolonel 7y ago
    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/libsodium/crypto_stream/chacha20/ref/chacha20_ref.c#L35 https://github.com/jedisct1/libsodium/blob/master/src/libsod...
- Spivak 7y ago
  > 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.
  - XelNika 7y ago
    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.

XelNika 7y ago

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.

CalChris 7y ago
I’m not sure that coexistence works without a version number going over the wire.
- XelNika 7y ago
  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.
  - CalChris 7y ago
    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.
    - XelNika 7y ago
      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.
- microcolonel 7y ago
  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/libsodium/crypto_stream/chacha20/ref/chacha20_ref.c#L35 https://github.com/jedisct1/libsodium/blob/master/src/libsod...
Spivak 7y ago
> 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.
- XelNika 7y ago
  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.