And yet the crowd that pushes WireGuard is the same crowd that pushes the idea that you can't give people a toolkit of crypto stuff, you have to give them a turnkey end-to-end system - indeed the fact that there's e.g. no algorithm selection in WireGuard is touted as a selling point. But how is making the user do their own key exchange/management any different? If you break the key management you break the cryptosystem.
Why should WireGuard bake all that stuff into the core protocol and at the same time make it overly complicated? Donenfeld knows zero about your organization and he doesn’t pretend to do so either. Are you an entusiast home user, a startup of six persons in a garage or are you IBM with over 300000 employees? All of those can use WireGuard but will have wildly different needs when it comes to authentication and deployment. There’s no sane one-size-fits-all solution for all kinds of organizations and use-cases.
> Why should WireGuard bake all that stuff into the core protocol
Because all that stuff is security-critical. All that stuff needs to be incorporated into any audit of the system. Indeed it's probably where the vulnerabilities are going to be.
> Are you an entusiast home user, a startup of six persons in a garage or are you IBM with over 300000 employees? All of those can use WireGuard but will have wildly different needs when it comes to authentication and deployment. There’s no sane one-size-fits-all solution for all kinds of organizations and use-cases.
There needs to be a system that can scale there, especially if the intent is to replace OpenVPN which slotted neatly into standard PKI. If this system pushes more users onto a handful of centralised providers, which seems like what's implicitly being encouraged, then that's not going to end up being good for security.
This argument doesn't make any sense. The more you couple to the underlying protocol, the harder it is to audit. Having a well-defined and predictable boundary between concerns in the system makes each component, and the system as a whole, easier to assess.
Having a predictable boundary and having modular crypto systems are two things that can sound similar, but are really pretty opposite.
To take the popular example: OpenSSL has a plethora of extensions. If there’s a thing you want to do, odds are the spec has been extended to cover that use case.
One result of that is that many code paths exist that aren’t part of everyday usage for most users, and so those code paths get less love (and more bugs): this makes things like Heartbleed radically more likely.
Another result is that parties using the system to communicate need to agree which modules/extensions they’re going to use. This kind of negotiation has been a punching bag for vuln after vuln, because it turns out some options are going to end up having weaknesses, and thus attackers can make their lives easier if they focus on tricking parties into downgrading to weaker modules.
By contrast, having Wireguard exclusively handle point-to-point tunnel behavior, without any negotiation of modules or extensions or similar, both simplifies the code paths and avoids runtime negotiation. Wireguard provides a boundary beyond that: it does not handle things like IPAM or a central authentication story, leaving those for another system to own. That system is then free to likewise provide a simple interface for whatever it’s doing, and gleaning all the same benefits.
> Wireguard provides a boundary beyond that: it does not handle things like IPAM or a central authentication story, leaving those for another system to own. That system is then free to likewise provide a simple interface for whatever it’s doing, and gleaning all the same benefits.
Right, but that system actually needs to be implemented, and the two need to be integrated together, and that part is where I suspect the vulnerabilities are likely to be, because the interface between two systems developed separately is always the most likely point for bugs and misunderstandings to creep in.
People talk about WireGuard having fewer vulnerabilities than OpenVPN and that may be true as far as it goes, but it's missing the fact that you can't simply replace OpenVPN with WireGuard - you would have to replace it with WireGuard plus some certificate management system plus some integration between them. And if everyone builds the last part themselves, it will almost certainly have security vulnerabilities.
