I feel there's some acronym substitution going on there!
> TCP does not support non-TCP protocols efficiently
I'm going to assume you meant TLS for the first of those :)
> TCP? No, it can handle dropped, duplicated and even reordered packets
And TLS is what I meant here, it generally doesn't like things being out of sequence, and TCP usually at least hides that from the application layer where TLS lives. Which I guess is why it is mostly dependent on TCP, but can be implemented (albeit less efficiently) over other reliable, in-order comms mechanisms.
I did in fact mean TCP/non-TCP over TCP (or more correctly, datagram semantics over TCP)! While this is possible, it usually removes all the performance benefits of using datagrams over streams in the first place.
That's presumably what Google is referring to with their statement about TLS not working well for non-TCP (more precisely: non-stream-semantics) traffic: Encapsulation of datagrams in streams is possible, but very inefficient. That's why VPNs using TCP generally suck for performance sensitive operations. (They usually also do TCP-over-TCP, which is even worse than stream-over-TCP.)
TLS does require stream semantics to work efficiently; its security guarantees don't break in the presence of reordering, duplication or datagram loss, but all of these would be interpreted as active attacks or severe uncorrected lower-layer failures and probably either cause abysmal performance or even application-level errors due to unexpected/unhandled alerts.
And why go through the effort if there is already DTLS, which is to UDP (and other datagram layers) what TLS is to TCP?
> TCP does not support non-TCP protocols efficiently
I'm going to assume you meant TLS for the first of those :)
> TCP? No, it can handle dropped, duplicated and even reordered packets
And TLS is what I meant here, it generally doesn't like things being out of sequence, and TCP usually at least hides that from the application layer where TLS lives. Which I guess is why it is mostly dependent on TCP, but can be implemented (albeit less efficiently) over other reliable, in-order comms mechanisms.