Comment by nickodell | Hacker News Reader

Comment by nickodell | Hacker News Reader

>In contrast, a hypothetical WireGuard protocol v2 can offer just two suites, the old one and the new one, with simple advice: use the new one if you can, and allow the old one for old nodes until they’re upgraded. There’s nothing unusual about this, except you don’t need to be a cryptography expert to configure it.

I don't think this is going to be as simple as the author thinks. Look at Git's migration away from SHA1. There was no designed mechanism for switching hash functions, and lots of code assumed 20-byte hashes. Three years after the first SHA1 collision was discovered, Git has not switched to a new hash function. I don't mean to be alarmist - no one has created a practical attack on Git objects, but the time to switch cryptographic primitives is when they start showing weakness, not after they are definitely broken.

IPSec has a standard method for supporting multiple cipher suites, and negotiating a common suite. It might be very complicated, but we have no way of comparing it to WireGuard, because WireGuard doesn't implement the same feature.

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.

>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.

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).

SHA1 was already found to be weak when git was made. Linus would have done better to use a strong hashing algorithm to begin with than to try to incorporate cryptographic agility. It was only found to be weak a few months before git's release though.

Regardless, I think cryptographic agility makes a lot more sense for a storage format like git than it does for a wire format. A shared repo being upgraded from gitv1 to an incompatible gitv2 would need everyone to switch versions at once. With WireGuard, a server could offer support for both v1 and v2 clients, then both v1 and v2 clients can connect to it at the same time, and clients can upgrade on their own schedule. The protocol doesn't have to make any special allowances, like making any data structures interpretable by both, besides to have both v1 and v2 on different ports or have different initial connection messages.

WireGuard was developed in response to protocols like IPSec, OpenVPN, and TLS, which emphasized configurability and cryptographic agility to a fault. Not only were they hard to use and easy to misconfigure, but each one of them were at times vulnerable to downgrade attacks because of subtle bugs in their ability to be configured. It's better to be able to have few code paths and verify they all work as expected, than it is to have many code paths, only verify the happy path, and hope that there's no way for users to fall down an unstudied insecure path by their own fault or because of attackers.

Doesn't agility make even less sense in a file format? Browsers, for instance, don't need format agility to tell a PNG from a JPG. Meanwhile, PDF tried to provide exactly that capability, and it is a world-historic security disaster. The cryptographic equivalent is PGP, and... I rest my case.

In git's case, by cryptographic agility I was imagining a Gitv2 which would produce SHA-256 hashes by default on new commits, and was able to still understand SHA-1 hashes on old commits so it could continue to read data produced by Gitv1 clients or Gitv2 clients in SHA-1 mode without needing an upfront convert-the-whole-repo step. Definitely less preferable than the alternative of just supporting SHA-256 from the very start though. May be less preferable to making git auto-convert repos forward to a new SHA-256-only version.

In his "L.T. on git" talk at google Torvalds said he used SHA1 not for security, that that would be elsewhere but he called sha1 the best (I think even most secure) hash out there. The serious most well know sha1 flaw was not discovered at that time AFAIK so not sure what you mean by already known as weak. And the fact that 3 years later git has not been broken proves its security does not rely on sha1 alone. I did not even know they are working on a change but good and makes sense of course.

Reply on news.ycombinator.com