Why not “Why not WireGuard?”(tailscale.com)
tailscale.com
Why not “Why not WireGuard?”
https://tailscale.com/blog/why-not-why-not-wireguard/
43 comments
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.
An interesting question is how will this play out with Wireguard going into the Linux kernel itself.
If holes are found in the underlying primitives,
all endpoints will be required to update.
An interesting question is how will this play out with Wireguard going into the Linux kernel itself.
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.
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.
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.
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...
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...
Glad someone did a rebuttal of that article. I came across it a few days ago and was shocked to discover it was by the guy behind ipfire, which I had previously heard good things about.
Yes, agree - the original article displays such a bad understanding of security that customers should avoid taking any operational advice, security-related or not, from the person who wrote it.
The author of the original article seems to be making the following assumptions:
- "Secure" is only about what protocols you support, and not about the quality of implementation, whether the protocols are implemented accurately, etc. In the author's world, Heartbleed (which was introduced as part of DTLS, part of Cisco's VPN implementation) doesn't exist, the Pulse Secure vulnerability that left Travelex completely non-operational doesn't exist, etc.
- That said, "3DES with MD5" is a good cryptographic protocol to use, and you should avoid fancier things like "AES-256 with SHA1."
- You should only consider using black boxes from companies like Cisco and Juniper (authors of Pulse Secure). If it's not compatible with those appliances, it's not worth using.
- You can't ever upgrade software in a reliable fashion. Everyone is running old, unpatched versions of software, and it's better for that unpatched software with all the well-known zero-days to connect to your corporate network than to be blocked from connecting.
- You should directly connect your internal network to "third parties that you do not control," and you should let those third parties dictate your software choices instead of vice versa.
In this world, you have nothing other than constant disasters. I guess it's good for job security, especially for someone whose job is professional support for IPsec.
It's a shame it needed debunking, but I'm glad someone did.
The author of the original article seems to be making the following assumptions:
- "Secure" is only about what protocols you support, and not about the quality of implementation, whether the protocols are implemented accurately, etc. In the author's world, Heartbleed (which was introduced as part of DTLS, part of Cisco's VPN implementation) doesn't exist, the Pulse Secure vulnerability that left Travelex completely non-operational doesn't exist, etc.
- That said, "3DES with MD5" is a good cryptographic protocol to use, and you should avoid fancier things like "AES-256 with SHA1."
- You should only consider using black boxes from companies like Cisco and Juniper (authors of Pulse Secure). If it's not compatible with those appliances, it's not worth using.
- You can't ever upgrade software in a reliable fashion. Everyone is running old, unpatched versions of software, and it's better for that unpatched software with all the well-known zero-days to connect to your corporate network than to be blocked from connecting.
- You should directly connect your internal network to "third parties that you do not control," and you should let those third parties dictate your software choices instead of vice versa.
In this world, you have nothing other than constant disasters. I guess it's good for job security, especially for someone whose job is professional support for IPsec.
It's a shame it needed debunking, but I'm glad someone did.
I agree with his point about software upgrades. Everyone is running old unpatched versions of software! WireGuard just externalities the messy upgrade process that will accumulate over time when you have to support devices and services that only support specific versions of the protocol. You’ll end up having to run multiple WG instances in the “transition period” that never actually ends rather than just negotiating the most secure thing you both support. And you can still cut people off from broken algos.
Having compatibility with the major vendors in the space is a real advantage because it’s a de facto standard I can get other companies and partners to agree on because they’re probably running one of those black boxes. You don’t have actually use any of them, but you will get a call down the road to interface with one of them.
I think the main thing is that WireGuard is a beautiful clean protocol that is about to get buried under piles of shoddy middleware to deal with the messy real world.
Having compatibility with the major vendors in the space is a real advantage because it’s a de facto standard I can get other companies and partners to agree on because they’re probably running one of those black boxes. You don’t have actually use any of them, but you will get a call down the road to interface with one of them.
I think the main thing is that WireGuard is a beautiful clean protocol that is about to get buried under piles of shoddy middleware to deal with the messy real world.
Then the first thing you need to do as part of setting up a VPN program is to figure out a software update process/policy that lets you push updates within hours and ensures you always do have the ability to patch (i.e., that you either know where you're getting updated binaries from for every client OS that connects or you know how to build them yourself). If you build a system where updates are part of the process, it works - take a look at say video games (which have far fewer people caring about their security than, like, the average corporate VPN), where having people on the latest version is just part of the expectations, and it works fine.
Otherwise, what's your plan for a Heartbleed-style scenario? Wait months for everyone to upgrade?
Otherwise, what's your plan for a Heartbleed-style scenario? Wait months for everyone to upgrade?
I feel like you’re assuming that I will have total control over every device that wants to connect which just isn’t realistic.
I mean the baseline case of a VPN that your employees use by both their work computers, personal computers, and phones. I can’t forcibly update all of those and politically I can’t cut people off because the truth is that being able to get work done is more important to the business.
Then I have to deal with vendor provided devices that are slow to receive updates or possibly will never receive updates ever. Again, I can’t just turn them off much as I would like to. No room in the budget to buy replacements. The old one is working fiiiine.
And then I have to deal with partners and oh boy I can’t even pretend to understand why they’re using an out of warranty Cisco box from 5 years ago but we make too much money through them to raise a fuss.
So that’s what I got. Everything I own gets migrated immediately. The help desk goes after everyone who doesn’t know how to update their apps. And we make special exceptions for random junk that can’t ever upgrade but is too valuable to turn off.
So yeah, you pretty much have to wait months for the stragglers but everyone who can upgrade does so immediately.
I’m sure lots of people here can tell lots of horror stories about turning off TLS 1.1.
I mean the baseline case of a VPN that your employees use by both their work computers, personal computers, and phones. I can’t forcibly update all of those and politically I can’t cut people off because the truth is that being able to get work done is more important to the business.
Then I have to deal with vendor provided devices that are slow to receive updates or possibly will never receive updates ever. Again, I can’t just turn them off much as I would like to. No room in the budget to buy replacements. The old one is working fiiiine.
And then I have to deal with partners and oh boy I can’t even pretend to understand why they’re using an out of warranty Cisco box from 5 years ago but we make too much money through them to raise a fuss.
So that’s what I got. Everything I own gets migrated immediately. The help desk goes after everyone who doesn’t know how to update their apps. And we make special exceptions for random junk that can’t ever upgrade but is too valuable to turn off.
So yeah, you pretty much have to wait months for the stragglers but everyone who can upgrade does so immediately.
I’m sure lots of people here can tell lots of horror stories about turning off TLS 1.1.
> I mean the baseline case of a VPN that your employees use by both their work computers, personal computers, and phones. I can’t forcibly update all of those and politically I can’t cut people off because the truth is that being able to get work done is more important to the business.
Then your priority isn't security. Which isn't necessarily a criticism, it's just a statement of what your business's priorities are.
Don't hide behind "well, IPsec supports all sorts of security knobs that can make it approximately as good as Wireguard, if you squint hard enough this is actually the more secure thing." Just say, no, security is not the top priority for this application, and we're going to design our systems around connectivity/reliability instead of security. You could decide security goes elsewhere the design, if you want, and add additional internal isolation once someone's on the VPN to avoid infected endpoints from messing with your corporate network. You could also just decide that a VPN isn't what you want, you want cloud services and BeyondCorp and the assumption of mostly-untrusted endpoints. (Then your users don't have to install VPN software at all, they just need a web browser.) Or for your partners with the out-of-warranty Cisco box - stick a firewall in front of them on your side and also arrange to use authenticated/encrypted application protocols as if you were connecting over the public network.
Or say, security and reliability are both priorities but cost isn't, we're buying everyone a work-managed laptop and a work-managed phone. (Or, if you really want to connect from your personal device, you can use a fully-patched one, and if you don't have one, the company will buy you one. Or whatever.)
But you cannot say that your priority is security and your priority is allowing unpatched devices to connect.
(I don't know anyone with a horror story about turning off TLS 1.1 who originally turned it on because they wanted secure connections. All of those people supported TLS 1.2 and the good ciphers before anyone forced them to. I know people with horror stories because they turned on TLS because they needed to check some regulator's checkbox.)
Then your priority isn't security. Which isn't necessarily a criticism, it's just a statement of what your business's priorities are.
Don't hide behind "well, IPsec supports all sorts of security knobs that can make it approximately as good as Wireguard, if you squint hard enough this is actually the more secure thing." Just say, no, security is not the top priority for this application, and we're going to design our systems around connectivity/reliability instead of security. You could decide security goes elsewhere the design, if you want, and add additional internal isolation once someone's on the VPN to avoid infected endpoints from messing with your corporate network. You could also just decide that a VPN isn't what you want, you want cloud services and BeyondCorp and the assumption of mostly-untrusted endpoints. (Then your users don't have to install VPN software at all, they just need a web browser.) Or for your partners with the out-of-warranty Cisco box - stick a firewall in front of them on your side and also arrange to use authenticated/encrypted application protocols as if you were connecting over the public network.
Or say, security and reliability are both priorities but cost isn't, we're buying everyone a work-managed laptop and a work-managed phone. (Or, if you really want to connect from your personal device, you can use a fully-patched one, and if you don't have one, the company will buy you one. Or whatever.)
But you cannot say that your priority is security and your priority is allowing unpatched devices to connect.
(I don't know anyone with a horror story about turning off TLS 1.1 who originally turned it on because they wanted secure connections. All of those people supported TLS 1.2 and the good ciphers before anyone forced them to. I know people with horror stories because they turned on TLS because they needed to check some regulator's checkbox.)
> Don't hide behind "well, IPsec supports all sorts of security knobs that can make it approximately as good as Wireguard,"
That's not really what I was getting at. I guess it would be something like "in situations where the priority is connectivity/reliability you will have better overall security with an IPSec deployment than a WireGuard one."
But otherwise I think your assessment is absolutely correct and we do employ pretty much all of those tricks.
Although the horror stories about TLS 1.1 is finding out just how many of your customers are running ancient clients that don't support TLS 1.2.
That's not really what I was getting at. I guess it would be something like "in situations where the priority is connectivity/reliability you will have better overall security with an IPSec deployment than a WireGuard one."
But otherwise I think your assessment is absolutely correct and we do employ pretty much all of those tricks.
Although the horror stories about TLS 1.1 is finding out just how many of your customers are running ancient clients that don't support TLS 1.2.
I agree the original article was really dumb, and sounded like it was written by an enterprise network guy who has only worked with and been trained by big vendors.
That said, the fatal flaw of Wireguard is the crypto model. Nobody who interacts with the US government, regulated US industries, or some F500 will be able to use it because of the fixed algorithm choice, which isn’t possibly FIPS 140-2 validatable. You’ll always need that Cisco/Pulse/whatever box.
That may be a feature for some, but it kneecaps the possibility of it being as ubiquitous as it might be otherwise.
That said, the fatal flaw of Wireguard is the crypto model. Nobody who interacts with the US government, regulated US industries, or some F500 will be able to use it because of the fixed algorithm choice, which isn’t possibly FIPS 140-2 validatable. You’ll always need that Cisco/Pulse/whatever box.
That may be a feature for some, but it kneecaps the possibility of it being as ubiquitous as it might be otherwise.
It's a trap, because your options boil down to:
(a) Using FIPS cryptography, which is inferior, to placate the USG.
(b) Using best-practices cryptography, and being incompatible with some places that mandate FIPS.
(c) Supporting both FIPS and non-FIPS cryptography, which creates handshake bugs and gives you lowest-common-denominator security.
I think you can reasonable argue that (a) and (b) are both superior to (c); I think WireGuard made the right choice here.
In the long run, for enterprise environments, I don't think this much matters. Even with FIPS cryptography, stodgy enterprises won't adopt WireGuard until it becomes so prevalent elsewhere that they have to, simply because IPSEC has more standardization. So the WireGuard task is simply to make it so prevalent everywhere else that stodgy enterprises no long have a vote.
(a) Using FIPS cryptography, which is inferior, to placate the USG.
(b) Using best-practices cryptography, and being incompatible with some places that mandate FIPS.
(c) Supporting both FIPS and non-FIPS cryptography, which creates handshake bugs and gives you lowest-common-denominator security.
I think you can reasonable argue that (a) and (b) are both superior to (c); I think WireGuard made the right choice here.
In the long run, for enterprise environments, I don't think this much matters. Even with FIPS cryptography, stodgy enterprises won't adopt WireGuard until it becomes so prevalent elsewhere that they have to, simply because IPSEC has more standardization. So the WireGuard task is simply to make it so prevalent everywhere else that stodgy enterprises no long have a vote.
I mean, we can just update the legislation to accept the competent ciphersuites, or the government can publish that once-in-a-century whitepaper where they demonstrate that DJB has been a brilliant CIA shill this whole time and the nothing-up-my-sleeve numbers have something up their sleeves.
Like, I get that that is not likely to happen, but the resistance of the state to competence is not an excuse for resistance to it outside the state.
Like, I get that that is not likely to happen, but the resistance of the state to competence is not an excuse for resistance to it outside the state.
When somebody absolutely positively cannot give up their hardware VPN box yet gets inundated with "WireGuard or die", that's the kind of bitter defensiveness that results. It's just human nature.
Who is giving “WireGuard or die” to people with hardware VPNs right now? It isn’t in any LTS releases right now and won’t be for another year.
This was released today: "WireGuard is included in Ubuntu 20.04 LTS and will be backported to Ubuntu 18.04 LTS to support widespread enterprise adoption."
Not sure about hardware VPNs, but I've seen people begging for Wireguard support in Private Internet Access for at least a year. I can imagine the ipfire guy getting similar requests a lot.
I can't wait for the tailscale app for Android.
If I die from covid before I get it I'll be very upset.
If I die from covid before I get it I'll be very upset.
(Co-founder here). It's coming, I promise. I'm as excited as you are. We wanted to iron out the kinks on mobile (i.e. iOS) before duplicating them on another platform. Thankfully, we're past that point now.
Finally, I've been waiting for someone to write a proper response debunking that original article. I was surprised when it got as much attention as it did, since it clearly seemed out of date.
I just wish the wireguard folks did IP6v2 :)
Kidding (kind of)!
Kidding (kind of)!
I recall skimming some recent(-ish) IPv6 overview RFC which was an update to an older RFC, ("IPv6 architecture", or something like that, maybe?) and IPSec has been demoted from necessary to optional.
So it's not entirely impossible IPSec will eventually fade into obscurity.
So it's not entirely impossible IPSec will eventually fade into obscurity.
I quite like Yggdrasil's [1] approach, and there are other alternatives. Of course, it doesn't fix everything, but with many project working on different aspects of networking, we might get back to an "internet" that's closer to a mesh between non-interoperable networks (GNU net, cjdns, private VPN-backed LANs, zigbee, etc).
Because, on your local network, you can run whatever you want (but it better be ipv6-aware software using DNS, it's easier to fool like NAT64 or yggdrasil do).
[1]: https://yggdrasil-network.github.io/
Because, on your local network, you can run whatever you want (but it better be ipv6-aware software using DNS, it's easier to fool like NAT64 or yggdrasil do).
[1]: https://yggdrasil-network.github.io/
Thanks for this - I'm not an expert at all in the networking space side of things, but even dabbling with ipsec / ipv6 combos made my head spin coming from an ipv4 background.
Basically I was left with the idea - how in the world is the gigantic set of interlocking RFCs (at least to me IPv6 seems to involve a lot of complex stuff) the best way to network these days.
Basically I was left with the idea - how in the world is the gigantic set of interlocking RFCs (at least to me IPv6 seems to involve a lot of complex stuff) the best way to network these days.
armaxt(1)
>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.
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.
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.
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).
[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.
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.
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.
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.
Maybe I don't understand the issue to be solved (I was unfamiliar with the 'road warrior' term so I looked it up [1]), but I think both Avery Pennarun and Michael Tremer misunderstood what WireGuard is capable of. WireGuard works just fine when the physical network interfaces have dynamic IPs (on both ends even). You can use the basic wg or wg-quick tools to create a VPN server on a server with a dynamic IP and have clients connect from dynamic IPs. However, all the tunnel IPs must be static unlike e.g. OpenVPN where the server gives the client a tunnel IP during authentication.
> (for example, so you can get to an office network whose home connection uses dynamic DNS). It’s true that plain WireGuard does not support this configuration out of the box.
I have done literally that for over a year now. I cannot think of a way to interpret this that would make Avery's claims true.
> Someday, WireGuard will need to be upgraded to support a second cipher suite. When this happens, users will be able to configure it peer-by-peer to allow one cipher suite or the other, or both, exactly as they would with any other VPN.
That is not how I interpret what Donenfeld has said [2] about the future of WireGuard. I believe the software will get a v2 without backwards compatibility. However, even that is a non-issue because sysadmins can run both protocols in parallel during the transition.
[1] https://en.wikipedia.org/wiki/Road_warrior_%28computing%29
[2] Page 3 of https://www.wireguard.com/papers/wireguard.pdf