It's not entirely WolfSSL's fault. TLS 1.3 is a mass of kludges and hacks to deal with the fact that they created a new protocol that's nothing like TLS 1.0-1.2 but dressed it up to make it look like TLS 1.2. It even lies about its protocol version in the handshake, hiding the real version in one of the many extensions they had to invent to kludge it into working. And in terms of RFC compliance, one of the most widely-used implementations isn't compliant, it doesn't send any of the mandatory-to-implement cipher suites in its client hello which means unless you want to trigger a rehandshake on every single connect you have to implement their non-compliant form of TLS 1.3.
The real problem though is that they made a protocol that really, really wants to pretend it's TLS 1.2 when it really isn't anything like TLS 1.2. I wouldn't blame "middleboxes" for getting confused when they encounter that.
The problem is there are many middleboxes that monitor port 443 and will drop any traffic that they can't decode as TLS (which in this case means TLS 1.2 or below). The choice was between masking traffic as an earlier version of TLS or forcing the replacement of all of those middleboxes. It's a no-brainer.
Then don't put it on 443 and pretend (badly) that it's TLS 1.2. Given that QUIC also uses 443 (and 80) without too many problems and that doesn't look anything remotely like TLS, presumably non-TLS 1.2 traffic to 443 is OK.
The problem isn't really the port used, it's the uncanny-valley approach they took in creating something that looks like a creepy zombie version of TLS 1.2, which keep-suspicious-things-out appliances quite rightly get suspicious over.
But QUIC doesn’t use 443/TCP; it uses 443/UDP. So it’s unsurprising that middleboxes that care about 443/TCP would ignore it. That doesn’t support your claim that “non-TLS 1.2 traffic to 443 is OK.”
The point I was trying to make, probably badly, was that there was no need to make TLS 1.3 pretend to be TLS 1.2 going to TCP/443. They could have picked some new port, called it TLS 2.0 (which is what it actually is), and run with that. If QUIC can pick its own port and, by the looks of it, not run into massive problems, there's no reason why TLS 2.0 can't do so too.
> wants to pretend it's TLS 1.2 when it really isn't anything like TLS 1.2.
I've seen a ton of this recently as Amazon has the option for TLS 1.3 with post quantum encryption on cloudfront now. A whole ton of different middleware shits itself.
The real problem though is that they made a protocol that really, really wants to pretend it's TLS 1.2 when it really isn't anything like TLS 1.2. I wouldn't blame "middleboxes" for getting confused when they encounter that.