The non-confidential stuff in headers only needs to be checked for integrity & authenticity. They just shouldn’t encrypt it. If it’s a tunneling protocol, one might make the encrypted packets have similar header info. Gotta be careful with stuff like that depending on how software is set up. In high-security setups, they’ll also have to overwrite packet fields on receiving side to eliminate covert storage channels. Possibly modulate their timing as well to knock out timing channels. Military always did fixed-time, fixed-size transmission for this.
“The companies that designed these protocols happen to control the servers and the client application program, but not really the client OS”
This isn’t entirely the case for QUIC, since Google does develop Android, which is easily the most popular OS in the world.
Google develop it, but that’s where it ends. They have basically no control over about getting any kernel level changes installed on actual running devices. 75% of the active Android Install base is on versions over two years old. And the much slower release cadence makes things even worse.
If they add a new TCP feature today to Android, in a year it’ll probably be running on 0.5% of devices. If they add a feature to QUIC on mobile Chrome, it’ll be on 80% of the devices in two months.