Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP)
updated by
- rfc-8996 — Deprecating TLS 1.0 and TLS 1.1
Extracted elements (25)
DTLS ApplicationData messages SHOULD use multiple SCTP streams other than stream 0 to minimize head-of-line blocking; using stream 0 exclusively is permitted for simplicity when head-of-line blocking is acceptable. Restricting control messages (handshake, alert, ChangeCipherSpec) to stream 0 ensures their ordered, reliable delivery.
DTLS was chosen over TLS for SCTP because TLS over SCTP (RFC 3436) does not support unordered delivery, partial reliability (RFC 3758), asymmetric stream counts, and requires one TLS connection per bidirectional stream. DTLS over SCTP overcomes all these limitations while preserving message boundaries and supporting dynamic address reconfiguration.
DTLS renegotiation is supported in DTLS/SCTP, but application writers should be aware that allowing renegotiations may result in changes of security parameters. The decision to allow or disallow renegotiation is left to the upper layer.
The DTLS/SCTP method requires that the SCTP implementation supports optional fragmentation of SCTP user messages (RFC 4960) and the SCTP authentication extension (RFC 4895). Both features are mandatory prerequisites for this protocol.
A DTLS CloseNotify message MUST only be sent after all outstanding SCTP user messages have been acknowledged by the peer and MUST NOT still be revocable. Prior to processing a received CloseNotify, all buffered SCTP user messages MUST be read and processed.
All DTLS messages of the ChangeCipherSpec, Alert, or Handshake protocol MUST be transported on SCTP stream 0 with unlimited reliability and ordered delivery.
Application protocols using DTLS over SCTP SHOULD register and use a separate PPID and SHOULD NOT reuse the PPID registered for running directly over SCTP, to facilitate protocol analysis and disambiguation.
Before sending a ChangeCipherSpec message, all outstanding SCTP user messages MUST have been acknowledged and MUST NOT be revocable by the SCTP peer. Prior to processing a received ChangeCipherSpec, all buffered SCTP user messages MUST be read and processed by DTLS.
DATA chunks of SCTP MUST be sent in an authenticated way as defined in RFC 4895. If PR-SCTP (RFC 3758) is used, FORWARD-TSN chunks MUST also be sent authenticated to prevent an attacker from forging chunk sequences to hide dropped messages.
DTLS Path MTU discovery MUST NOT be used when running over SCTP, because SCTP already provides Path MTU discovery and fragmentation/reassembly for user messages.
DTLS procedures for retransmissions MUST NOT be used, because SCTP provides a reliable and in-sequence transport service for DTLS messages that require it.
DTLS replay detection MUST NOT be used when running over SCTP. Because DTLS/SCTP provides a reliable service if requested by the application, replay detection at the DTLS layer would incorrectly drop retransmitted SCTP messages.
Each DTLS connection MUST be established and terminated within the same SCTP association. A DTLS connection MUST NOT span multiple SCTP associations.
Every SCTP user message MUST consist of exactly one DTLS record. This one-to-one mapping between SCTP user messages and DTLS records is a fundamental structural constraint of the protocol.
For the purposes of running over SCTP, the DTLS path MTU MUST be considered to be 2^14 bytes. This allows DTLS to send maximum-sized messages and offloads fragmentation to SCTP.
Once the corresponding Finished message from the peer has been received, the old SCTP-AUTH key SHOULD be removed to limit exposure of old keying material.
The endpoint-pair shared secret for Shared Key Identifier 0 MUST be empty and used when establishing a DTLS connection. Whenever the master key changes, a 64-byte shared secret MUST be derived using the TLS exporter (RFC 5705) with the label from Section 5 and no context.
The new Shared Key Identifier MUST be the old one incremented by 1; if the old one is 65535, the new one MUST be 1. Before sending the Finished message, the active SCTP-AUTH key MUST be switched to the new one.
The supported maximum length of SCTP user messages MUST be at least 18445 bytes (2^14 + 2048 + 13), and the SCTP implementation MUST support fragmentation of user messages to accommodate full-sized DTLS records.
User messages that arrive between ChangeCipherSpec and Finished using the new epoch MUST be buffered by DTLS until the Finished message is read, to handle the epoch transition correctly during handshake.
The maximum DTLS user message size is 2^14 bytes, which is the DTLS limit. Additionally, the DTLS user cannot perform SCTP-AUTH key management because this is handled by the DTLS layer.
IANA added the label 'EXPORTER_DTLS_OVER_SCTP' to the TLS Exporter Label registry (RFC 5705). This label is used to derive the endpoint-pair shared secrets for SCTP-AUTH key management.
DTLS endpoints may be authenticated based on IP addresses in certificates, but SCTP associations can use multiple addresses per endpoint. DTLS records may therefore arrive from a different IP address than originally authenticated; security decisions MUST be based on the peer's authenticated identity, not its transport-layer IP address.
DTLS supports cipher suites containing a NULL cipher algorithm. Negotiating a NULL cipher will not provide communications privacy or message confidentiality for application user messages.
The stream identifier, ordered/unordered delivery flag, and payload protocol identifier (PPID) in SCTP DATA chunk headers are not protected by DTLS and are transmitted in clear text, even when DTLS encryption is active for the application data payload.