I get the impression that the arrow of causation points in the other direction: network device implementers and network operators frequently accidentally mishandle or try to ban traffic that is outside the bounds of what they understand. So, to work around the damage, new stuff has to tunnel through the gaps.
So you get things like mptcp which is carefully designed to make each path look like a single flow, even though the application-level flow is sharded across multiple paths. And TLS/1.3 for which the last several months involved making the protocol look more and more like TLS/1.2 so that it can avoid bugs in middleboxes.
DoH is a bit different... as I understand it, the main motivation is to make the dns available to in-browser js apps, without doing too much damage to the web security model. The tunnelling aspect is more a side-effect than a deliberate attempt to bypass lossage. But the reasons for specifying it really have no influence on how people will use it, and that is where the weird consequences will happen...
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
no subject
Date: 2018-03-26 20:22 (UTC)So you get things like mptcp which is carefully designed to make each path look like a single flow, even though the application-level flow is sharded across multiple paths. And TLS/1.3 for which the last several months involved making the protocol look more and more like TLS/1.2 so that it can avoid bugs in middleboxes.
DoH is a bit different... as I understand it, the main motivation is to make the dns available to in-browser js apps, without doing too much damage to the web security model. The tunnelling aspect is more a side-effect than a deliberate attempt to bypass lossage. But the reasons for specifying it really have no influence on how people will use it, and that is where the weird consequences will happen...