If TLS 1.3 will fail, I doubt QUIC will make it through. I'm no fortune 100 sysadmin but if I were that worried about network traffic, I wouldn't allow some unknown UDP protocol to go out unnoticed.
I don't know where these middleboxes are but this doesn't seem that important until people report having issues. It's been five years since TLS 1.3 was introduced and even longer since the survey that led to the compatibility mode was conducted, many companies with bad middleboxes will probably have had to upgrade them by now.
It's not a problem of being paranoid about TLS. It's a problem with well intended middleboxes which worked at the time, but now do harm instead. It's easy to say that people should of updated by know. But that's hard to force when nobody fully knows what will break ( ipv4 to ipv6 for example).
QUIC works better becuase UDP haven't gotten the same treatment as TCP and TLS. It brings with it other problems . One problem for example being NAT's sometimes poor handling of long lasting UDP connections. But QUIC has functionality to handle that.
> I wouldn't allow some unknown UDP protocol to go out unnoticed
A bit of a compromise has been made in this regard by using something called a spin bit.
I've been on several networks that blocked all outgoing UDP traffic because "it's for file sharing and we don't allow that". It's just as easy to say UDP somehow gets special treatment in an environment where protocol parsing DPI is the norm. I've even used infuriating networks that explicitly sabotaged QUIC because their middlebox couldn't parse it, whereas standard TLS 1.3 worked just fine.
The problematic middleboxes are the ones that don't forward packets they can't parse. If they would correctly identified traffic as "TLS but too recent to parse" and let the packets flow through, we wouldn't have this problem. For that reason I strongly doubt that anywhere these boxes are employed UDP traffic somehow goes by unnoticed, because there's layer 3 filtering going on wherever these boxes fail.
>I've been on several networks that blocked all outgoing UDP traffic because "it's for file sharing and we don't allow that".
I think we're thinkig about different things when it comes to middleboxes. It's not about networking rules on LAN. More about middleboxed that do queue management traffic prioriyy etc on MAN and WAN levels. If a network administrator wants to block something then so be it.
>For that reason I strongly doubt that anywhere these boxes are employed UDP traffic somehow goes by unnoticed
UDP doesn't go by unnoticed in these cases, but is more or less ignored in a way that TCP is not. UDP can't be blocked on WAN and MAN level as it's was widely used before middleboxes became a thing. New protocols however can't be introduced. Hence the QUIC solution. If you're interested in it more then MPTCP is also an interesting example of this
Middleboxes that merely apply traffic shaping don't need to parse TLS headers, though. For optimising HTTPS flows, tcp/443 is good enough.
UDP often gets special treatment in that it gets dropped more often when the unlink becomes saturated. After all, UDP has no delivery guarantee so dropping the packets is less likely to cause retransmissions and other noise. DNS traffic may be excluded from this treatment, but I'd expect such shapers to also implement a transparent caching DNS proxy for performance improvements.
I don't know where these middleboxes are but this doesn't seem that important until people report having issues. It's been five years since TLS 1.3 was introduced and even longer since the survey that led to the compatibility mode was conducted, many companies with bad middleboxes will probably have had to upgrade them by now.