Must, Should, Don't Care: TCP Conformance in the Wild • Hacker News Board

Re: Must, Should, Don't Care: TCP Conformance in the Wild

#51

Post by tialaramex » Tue, Apr 07, 2020, 1:56 PM UTC

touisteur wrote: post #49

tialaramex wrote: post #45

Earlier quoted context omitted.

> What's missing in SCTP (used everywhere in telephony/3-4-5g, right?) that we had to reinvent another complete transport+session layer ? SCTP isn't encrypted. Because "Pervasive Monitoring is an Attack" new IETF protocols should be encrypted or explain why they can't be. HTTP/2 for example is in effect always encrypted (the document explains how one could in theory build an unencrypted variant but nobody implements…

Ah, encryption, thanks. Thought there was a sctp+tls RFC https://tools.ietf.org/html/rfc3436 don't know whether any userland lib supports this with sctp-over-UDP.

I explained the negative consequences of just layering TLS on top in my comment already.

RFC3436 just makes pairs of SCTP streams (one in each direction) into a transport like TCP that TLS will run on top of. Each such stream-pair then does a TLS handshake.

That's not what QUIC does. The entire QUIC connection, however many streams and in whichever direction, is encrypted.

As a very simple example - suppose you spin up three parallel stream pairs to fetch three separate documents over a hypothetical HTTP-over-TLS-over-SCTP. With RFC 3436 you reveal to an on-path adversary that there are three streams, and they get to see how much data travelled over each stream. But with QUIC it's just an opaque pipe, the on-path adversary can see how much data was transmitted each way but can't determine whether that's one document in one stream, or ten documents in two streams or anything else.

Re: Must, Should, Don't Care: TCP Conformance in the Wild

#52

Post by touisteur » Tue, Apr 07, 2020, 4:02 PM UTC

tialaramex wrote: post #51

touisteur wrote: post #49

Earlier quoted context omitted.

Ah, encryption, thanks. Thought there was a sctp+tls RFC https://tools.ietf.org/html/rfc3436 don't know whether any userland lib supports this with sctp-over-UDP.

I explained the negative consequences of just layering TLS on top in my comment already. RFC3436 just makes pairs of SCTP streams (one in each direction) into a transport like TCP that TLS will run on top of. Each such stream-pair then does a TLS handshake. That's not what QUIC does. The entire QUIC connection, however many streams and in whichever direction, is encrypted. As a very simple example - suppose you spin…

Sorry I did not mean to say you were wrong, I just meant to say 'it exists', for reference. I understood your first explanation, didn't know whether this RFC encrypted substream by substream or the whole session (I should have read more before posting). Thanks for the clarification. And your patience.

Re: Must, Should, Don't Care: TCP Conformance in the Wild

#53

Post by yencabulator » Sat, Apr 18, 2020, 3:52 PM UTC

dirtydroog wrote: post #12

HTTP is in a similar sorry state. For example, it offers pipelining support but nobody can reliably use it because it probably won't work on some forgotten about machine somewhere on the path.

Another example: Setting Allow header properly in a 405 response is a MUST. I am not aware of anything that breaks due to missing that, and I am aware of many implementations that do not set it.