Implementing a security layer (TLS) on top of an untrusted communication layer (TCP or UDP) without any binding could only cause problems related to protocol ossification at middleboxes (those being, indeed, MITM devices), leading to potential communication disruptions and possible denial of service for certain groups of users or networks.
This is what the QUIC protocol (the modern TLS/TCP replacement) is being designed against.
But (save for occasional denial of service problems) no other security issues could arise because the underlying communication protocol is meant to be untrusted anyway.
However, the paper you're referring to ("Authentication Binding between SSL/TLS and HTTP") tells quite the opposite: implementing a communication protocol on top of a security layer without proper enforced binding could cause implementation issues. This is called the law of leaky abstractions.
A (somewhat) simpler example of how this could happen in practice is domain fronting:
- TLS — the security layer — features a concept of Server Name Indication (SNI) — a token that could be used by a client to tell the TLS server which service exactly they want to reach.
This concept and a corresponding SSL/TLS extension were developed long time ago and served the purpose of having multiple TLS services, with multiple certificates, available via a single IP-address-and-port tuple. One example where it was strongly needed had been initially shared hosting, but there were also other applications that started to make use of SNI over the years.
- There's a matching concept in the HTTP protocol: the server name, transmitted as a value of the "Host" header.
The TLS server name and HTTP server name are values which come from the same namespace — known as the "Internet domain names" namespace — and in case an HTTP session is established on top of a TLS session, RFC 6066 states that both server names should generally match each other (if there’s no clear purpose and intent by the authors of an implementation to do it the other way).
However, it's up to the HTTPS server's authors to implement this constraint, as the server name from TLS layer isn't automatically inherited in HTTP session.
- A common application layer protocol implementation mistake is to use TLS just for session establishment, forgetting entirely to check that the TLS hostname negotiated before matches what client now provides on the application layer.
NB: in a large corporate or cloud network it gets even worse, because
sometimes the TLS session is terminated on a specific piece of
equipment — say, a balancer or a firewall — yet the HTTP session is
being terminated far away from that.
This way, the HTTP server gets no
instrument at all to verify that both server names match, and the firewall
may omit this check either.
As a side effect, also not usually meant to be present by the software developers, user can take an arbitrary TLS layer name to reach a Web site they want to access without disclosing their intent in cleartext during TLS session establishment. However, as a matter of fact, there are more side effects of this, and under certain circumstances this mistake in the code — or the infrastructure — may even result in a serious vulnerability.
- For instance, when client TLS certificates are used for authentication, an attacker can circumvent the authentication by providing a server name of an adjacent TLS service which doesn't require certificate authentication, and then supplying the host name of a desired application layer service after all the TLS layer checks succeeded.
Protocol specifications and implementations usually implicitly rely on the TLS server name and the application layer name being the same, and without a proper binding here other security problems could later appear.
