3 ms·
Ah, encryption, thanks. Thought there was a sctp+tls RFC https://tools.ietf.org/html/rfc3436 https://tools.ietf.org/html/rfc3436 don't know whether any userla
by touisteur 7y ago
Ah, encryption, thanks.
Thought there was a sctp+tls RFC https://tools.ietf.org/html/rfc3436 https://tools.ietf.org/html/rfc3436
don't know whether any userland lib supports this with sctp-over-UDP.
- tialaramex 7y agoI 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.
- touisteur 7y agoSorry 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.