I work in the field and anybody that says that a piece of software is secure before it has even had a security evaluation by a third party does not know what they are talking about.
I think what you have seen is security people saying that the design of Wireguard seems to be equal or better than other, current, options, that doesn't mean that the implementation is just yet.
I've spent my career doing third-party software security evaluations --- among other things, I founded the NCC Cryptography Services practice --- and I will tell you right now that the Wireguard security story is far more compelling than any third-party audit.
It's not simply the protocol design, which is superior in pretty much every conceivable way to IKE or TLS, but also the code, which is carefully written to minimize attack surface and increase reviewability.
Choosing OpenVPN or StrongSWAN over WireGuard to minimize exposure to vulnerabilities would be a dumb bet. Sometimes dumb bets pay off, but it's still dumb to make them.
Could you unpack your statement about the careful code writing, or link to an explanation? We would usually expect a formal third-party audit to substantiate such a claim, but if there is other good evidence for their code's secure implementation I'd love to see it.
First, I'm going to try not to go into this in detail right now, but HN has very weird ideas about the potency of third-party code audits, particularly for things involving cryptography. A short summary: most third-party audits of cryptographic software written in systems languages don't accomplish anything. Most crypto software you depend on has never had a full-coverage audit from third-party auditors qualified to evaluate crypto.
You can watch any talk about WireGuard to see what I mean about the way WireGuard's code is written, but the short answer is that the thing was designed from the bottom up to be simple. WireGuard's feature selection was influenced strongly by what would keep the codebase smaller and easier to review. It was also designed to simplify the object lifecycle inside the code itself. All its state is preallocated at initialization.
WireGuard's cryptography is essentially an instantiation of Trevor Perrin's Noise framework. It's modern and, again, simple. Every other VPN option is a mess of negotiation and handshaking and complicated state machines. WireGuard is like the Signal/Axolotl of VPNs, except it's much simpler and easier to reason about (cryptographically, in this case) than double ratchet messaging protocols.
It is basically the qmail of VPN software.
And it's ~4000 lines of code. It is plural orders of magnitude smaller than its competitors.
WireGuard isn't a panacea. In particular: clientside support for it isn't there yet! But it's pretty clear to me at least that WireGuard should imminently be replacing OpenVPN and IPSEC.
I agree with you. It needs formal evaluation by pros with time to dig into it with review and tool-assisted analysis. That said, a person as experienced at pentesting as tptacek saying the crypto and code looked good puts its trustworthiness above most options in my eyes. I mean, you rarely here good things about both in such software. The quality of average development in crypto is just that bad. I also liked what I saw when I looked at it in terms of simplicity.
I only know Thomas via his output, but will say that based on it, he very much knows what he is talking about when it comes to the design and implementation of security protocols.
I think what you have seen is security people saying that the design of Wireguard seems to be equal or better than other, current, options, that doesn't mean that the implementation is just yet.