> Noise isn't a protocol, it's a recipe for building protocols. So this is like suggesting QUIC WG having bought all the rest of the furniture for the house should instead of buying this ready made dining table & chairs that fit the rest of the house perfectly buy a book on carpentry and chop a tree down to start making the table by hand.
Take a look at nQUIC: https://eprint.iacr.org/2019/028
> Noise isn't interested in the handshake problem, which is 95% of TLS
That's part of my point. If you do not need TLS, now suddenly you rely on this huge dependency and you have to figure out x509 certificates.
Most situations which would /not/ be happy with TLS here will likewise find things not to like in any particular hypothetical Noise-based TCP replacement, because the parameters of the recipe matter to them. They'd like a different hash function, different type of symmetric encryption, or different DH. In Noise the only way to do that is start over, like if during final assembly of the table you decided you want a pine table not an oak one. So these people would most likely insist on using Noise for their own custom protocol anyway regardless of what QUIC does.
And if you _do_ use the Noise recipe it's not as though you just throw in the elements you've chosen and out pops a replacement for TLS. Noise isn't interested in the handshake problem, which is 95% of TLS, it's just waved away as something you should solve for yourself. For a VPN like WireGuard that's not crazy - in practice many VPN setups did this, or worse, already. But for most TCP connections (even ignoring the Web) it's a non-starter.
So Noise replaces 5% of what TLS does for QUIC, and only once you've picked your ingredients. It's a bad trade.