3 ms·

> TLS also does not support non-TCP transport protocols eh? TLS is a record based protocol and you can use it over bits of paper transported by pigeon if you

by Nursie 4y ago

> TLS also does not support non-TCP transport protocols eh? TLS is a record based protocol and you can use it over bits of paper transported by pigeon if you like, can't you? I've looked into it extensively (though not for a few years I'll admit), and I've seen TLS implementations that don't include any transport mechanism - that bit it left to the application. I know that it must receive things in-order, and perhaps that does rule out UDP... but there's DTLS :) That doesn't mean this isn't interesting, and I have no idea how 'offloadable' TLS or DTLS might be. This scheme seems to use derivable keys, so that packet sequence isn't important, but it looks also like we have a mac-then-encrypt scheme. I presume it's been analysed properly... Definitely worth digging into.

lxgr 4y ago
TCP does not support non-TCP protocols efficiently (since any type of tunneling or encapsulation necessarily enforces at least some TCP semantics on whatever is being tunneled). > I know that it must receive things in-order TCP? No, it can handle dropped, duplicated and even reordered packets, but doing so is problematic for many applications (either due to real-time requirements or adverse network conditions that a given TCP implementation doesn‘t handle well).
- Nursie 4y ago
  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.
  - lxgr 4y ago
    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?

by Nursie 4y ago

lxgr 4y ago

TCP does not support non-TCP protocols efficiently (since any type of tunneling or encapsulation necessarily enforces at least some TCP semantics on whatever is being tunneled). > I know that it must receive things in-order TCP? No, it can handle dropped, duplicated and even reordered packets, but doing so is problematic for many applications (either due to real-time requirements or adverse network conditions that a given TCP implementation doesn‘t handle well).

Nursie 4y ago
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.
- lxgr 4y ago
  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?