QUIC uses Web PKI and TLS. TLS is not a simple protocol and the main reason to use it over something simpler is if you need it to be compatible with something else that already uses it, like HTTPS.
The main reason to use TLS is that you can get a bunch of off-the-shelf implementations that are (post-Heartbleed) the most heavily scrutinized public cryptographic implementations in existence. Plus if anyone finds a practical exploit of TLS (or a major implementation), they’re more likely to go steal credit card numbers being typed into Amazon than to attack your particular use of it. Noise is cool but if you don’t need the same flexibility that Wireguard does (or have the expertise to implement a concrete protocol on top of it correctly), something built on TLS 1.3 is a better bet.
I'm not even convinced that a random TLS library would get non-trivially more scrutiny than Wireguard does, and on top of that it would need more scrutiny because it's significantly more complicated which is a synonym for attack surface.
And the "more valuable targets" argument is self-defeating because if there aren't as many high value targets using something then there aren't as many attackers looking for vulnerabilities in it either. Moreover, if someone finds one in TLS (or anything) then they can launch exploits against multiple targets simultaneously rather than waiting to move on to the second target until after the first investigates the attack and publishes a patch for everyone else to use.
Sure, they’ll get every credit card typed into Walmart’s website too. Cisco’s IKE implementation has had vulnerabilities (definitely still more widely deployed than Wireguard unfortunately), but almost nobody has heard about those. I don’t think they even had a cutesy name!
My point isn’t that Wireguard should’ve used TLS/QUIC. Is that if you want a connection oriented transport encryption, you should almost certainly use TLS 1.3 in some fashion even if web compatibility isn’t a concern.
