TLS handshake over SCTP streams

Question

I was going through the TLS support over SCTP rfc, where i could see the spec quoting that the TLS handshake has to be done over every bidirectional streams before initiating message transfer over the transport.

5. Connections and Bi‐directional Streams

TLS makes use of a bi‐directional stream by establishing a connection over it. This means that the number of connections for an association is limited by the number of bi‐directional streams. The TLS handshake protocol is used on each bi‐directional stream separately.

So if i have 5 SCTP bidirectional streams opened, does it mean i have to do the key exchange, certificate validation etc. seperately on each of the 5 bidirectional streams ?

I am asking this because i find it so odd that the protocol design wants the developer to repeat TLS handshake on each stream, even though the socket opened is just one, and its the same handshake being done over each of the streams opened.

I also tried writing a sample TLS over SCTP code, where TLS handshake was done over stream 0, and i was able to do the data transfer over all the 5 streams.

So is it some spec mandatory stuff to be done? what happens if i do the handshake over just one stream and data transfer over all the associated streams ? is there any security vulnerability associated ?

Someone please enlighten me on this.

Answer 1

Meta: this isn't really a programming problem. It would probably fit better on security.SX which covers SSL/TLS extensively, and DTLS some, although not SCTP that I can recall.

TLS assumes and requires the service provided by TCP, namely a (single) in-sequence octet stream, where data is delivered in order without loss or duplication or reordering, unless the connection fails in which case data delivery stops entirely and detectably. The record format and integrity check algorithms (HMAC or AEAD) rely on this. If you send part of the 'wire' format for TLS over stream A and another part over stream B, and the part on B arrives before that on A, or A is delivered but B is lost or vice versa, TLS will lose bigtime.

There are two possible solutions:

• Don't use FULL handshake. TLS (and SSL before it) includes session 'resumption' which uses the results (primarily the negotiated master secret) of a previous handshake that both parties have cached, often with some time limit like an hour or a day. This avoids the often costly public-key cryptography (key encryption or agreement and certificate validation) and also the possibly time-consuming out-of-band cert checks (unstapled OCSP or CRL or alternative). It uses an 'abbreviated' handshake of only 1.5 exchanges: ClientHello, ServerHello plus CCS and Finished, CCS and Finished, all of which are short except possibly ClientHello.

  The examples in sections 8.2 8.3 8.4 of rfc3436 use (and implicitly recommend) this.

  There is an optional alternative form of session resumption, not much used, which reduces the load on servers in a many-to-one (or many-to-few) situation, where instead of the server actually caching its information about a session, it provides the client an encrypted/sealed 'ticket' that the client sends back.

• Use DTLS. There is also a variant protocol, Datagram TLS rfc4347 matching TLS1.1 or rfc6347 matching TLS1.2 which does its own fragmentation (handshake only) and sequence numbering. This doesn't require transport any better than UDP offers, which is that any delivered datagram corresponds to one that was sent, but datagrams can be lost, duplicated, or misordered. It will thus work over SCTP, although there is some inefficiency in having both protocol levels add overhead for sequencing.