I'm annoyed TLS 1.2 compatibility mode is still required. Is there a way to turn it off, accepting that people with incompetent network administrators can't access your website, or have shitty middleboxes forever ruined TLS?
One way of solving this is by circumventing the middleboxes. This is more or less the way QUIC works. QUIC uses UDP which avoid most middleboxes and their failed attempts at being helpful. So QUIC can without issue upgrade to a new version of TLS without middleboxes ruining it, while TLS over TCP is stuck (at least for the moment). This brings with it other issues, but hey one problem solved at least.
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.
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.
https://greenbytes.de/tech/webdav/draft-ietf-quic-spin-exp-l...
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 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
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.