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.
