]> Ericsson

magnus.westerlund@ericsson.com

Ericsson

john.mattsson@ericsson.com

Ericsson

claudio.porfiri@ericsson.com

Transport TSVWG This document defines how Transport Layer Security (TLS) 1.3 is used as a key-management method for the SCTP DTLS Chunk mechanism. It specifies how a TLS handshake establishes the initial security context for an SCTP association and how subsequent TLS handshakes provide key updates and re-authentication. The goal is to enable authenticated and confidential communication over SCTP using the DTLS Chunk, leveraging standardized TLS 1.3 features for key management and rekeying. About This Document Status information for this document may be found at . Discussion of this document takes place on the Transport Area Working Group (tsvwg) Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction The Stream Control Transmission Protocol (SCTP) is a transport protocol designed to support message-oriented communication with features such as multi-streaming and multi-homing. In many deployments, particularly telecommunication networks and WebRTC data channels, it is essential to provide confidentiality, integrity, and peer authentication for SCTP traffic. defines a mechanism for securing SCTP by encapsulating SCTP chunks within DTLS 1.3 records at the chunk level. That specification defines the DTLS chunk format, negotiation procedures, and an abstract API for key management, but delegates the actual key management to external methods identified by a DTLS Key Management Identifier. This document defines one such method: it uses TLS 1.3 handshakes carried as SCTP user messages to perform mutual authentication and derive keying material for the DTLS Chunk Protection Operator. The combination of the SCTP DTLS Chunk and the key-management defined in this document is referred to as "TLS for DTLS in SCTP". The key advantages of this approach are:

• It requires no extensions to TLS 1.3 to support long-lived sessions.
• It is based on TLS 1.3 rather than DTLS 1.3, leveraging widely available TLS implementations.

Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. In this document, || denotes concatenation of byte sequences.

Terminology This document uses the following terms:

Association:

An SCTP association.

Connection:

A TLS 1.3 connection used for key management.

DTLS Key Context (DKC):

The keying material (record payload key, sequence number key, and IV) for both send and receive directions, together with the replay window and last used sequence number. Each DKC is identified by a tuple of (SCTP Association, restart indicator, DTLS epoch).

Initiator:

The endpoint assigned the client role during SCTP association establishment. This corresponds to the "client" role (C bit) in the DTLS Key Management Parameter of .

Primary DKC:

A DTLS Key Context used to protect regular SCTP association traffic.

Responder:

The endpoint assigned the server role during SCTP association establishment. This corresponds to the "server" role (S bit) in the DTLS Key Management Parameter of .

Restart DKC:

A DTLS Key Context reserved exclusively for the SCTP association restart procedure.

Abbreviations

AEAD:

Authenticated Encryption with Associated Data

DKC:

DTLS Key Context

DTLS:

Datagram Transport Layer Security

PPID:

Payload Protocol Identifier

SCTP:

Stream Control Transmission Protocol

TLS:

Transport Layer Security

ULP:

Upper Layer Protocol

Overview This section provides an informational overview of TLS for DTLS in SCTP. Normative procedures are specified in .

Architecture

Architecture + Key Exporter +--+ | | | | | +---------------------+ | | | | | | | | | | | | +---------------------+ | | | | | +--+ Key Management + | | | | | | +----------+----------+ | | | | | | | | | | | | | ContentType | | | | | | | +----------+----------+ | | | | | +->| TLS Record | | | | | | | Protection Operator | | | | | | +----------+----------+ | | +-------+-------+ +-----------------------------+-+ ^ ^ | | | | +--+-----------------------+ | keys PPID | | V V +-----------------------------------------------+-+ | +---------------------+ | | | SCTP | DTLS Chunk |<---+ | | | Protection Operator | | | +---------------------+ | +-------------------------------------------------+ ]]>

Application data is never transmitted in TLS application_data records. Instead, application data is sent via SCTP DATA chunks protected by the DTLS Chunk Protection Operator. TLS 1.3 is used solely for key management: performing handshakes, deriving keys via the TLS Exporter, and then closing the TLS connection.

Protocol Flow Summary The protocol operates in three phases:

1. Initial Establishment: After SCTP association setup (with DTLS Key Management Parameter negotiation), a TLS 1.3 handshake derives the initial Primary and Restart DKCs. Protection is then enforced.
2. Rekeying: Either endpoint initiates a new TLS 1.3 handshake to derive fresh DKCs for the next epoch, providing forward secrecy and re-authentication. Old DKCs are removed after draining.
3. SCTP Restart: The pre-established Restart DKC protects the COOKIE ECHO/COOKIE ACK exchange, followed by a new TLS handshake to establish fresh Primary and Restart DKCs.

TLS Configuration Requirements

TLS Version This document defines the usage of TLS 1.3 . Earlier versions of TLS MUST NOT be used. Only one version of TLS MUST be used during the lifetime of an SCTP Association.

Cipher Suite Constraints Parameters not marked as "Y" in the "Recommended" column of TLS registries are NOT RECOMMENDED to support. Non-AEAD cipher suites or cipher suites without confidentiality MUST NOT be supported. Cipher suites and parameters that do not provide ephemeral key-exchange MUST NOT be supported. The cipher suites negotiated in the key-management TLS connection MUST only include those supported by the DTLS Chunk Protection Operator. The DTLS Chunk provides an API to query supported cipher suites (see Section 7.3 of ).

Authentication and Identity TLS for DTLS in SCTP MUST be mutually authenticated. It is RECOMMENDED to use certificate-based authentication. When certificates are used, the application is responsible for certificate policies, certificate chain validation, and identity authentication. The application defines what the identity is and how it is encoded. Guidance on server certificate validation can be found in . All security decisions MUST be based on the peer's authenticated identity, not on its transport layer identity. Since SCTP associations can use multiple IP addresses per endpoint, DTLS records may arrive from different source IP addresses than those originally authenticated. Clients and servers MUST NOT accept a change of identity during the setup of a new TLS connection, but MAY accept negotiation of stronger algorithms and security parameters.

Rekeying Policy Implementations MUST have policies for how often to set up new TLS connections with ephemeral key exchange. Implementations SHOULD rekey at least every hour and every 100 GB of data, which is a common policy for IPsec . Implementations MUST set up a new TLS connection using a full handshake before any of the certificates expire. The PSK key exchange mode psk_ke MUST NOT be used as it does not provide ephemeral key exchange. TLS Key Update MUST NOT be used. TLS 1.3 tickets MAY be used for resumption (valid up to seven days). Resumption can be used to chain the connections, increasing security by forcing an adversary to break them in sequence . The endpoints MUST limit the number of simultaneous TLS connections to one.

TLS Message Transport TLS records and control messages for key-management are sent as SCTP user messages using reliable in-order delivery on stream 0 with the DTLS Key Management Messages PPID (4242) . Each SCTP user message uses the format defined in .

Key Management User Message Structure

T (Message Type): 1 bit

Indicates the type of payload carried in this user message. A value of 0 indicates that the payload contains TLS records. A value of 1 indicates that the payload is a control message (see ).

Epoch: 7 bits

The 7 lowest bits of the DTLS Key Context epoch that this message corresponds to — i.e., the DKC that will be created from this handshake, or that already exists. The receiver uses this field to associate incoming data with the correct key-management session.

Payload: variable length

When T=0, one or more complete TLS records. When T=1, a control message as defined in .

Control Messages When the T bit is set to 1, the payload of the user message is a control message with the following format:

Control Message Format

Ctrl Type: 8 bits

Identifies the control message type.

Control Data: variable length

Type-specific data. May be empty.

The following control message type is defined: Control Message Types

Ctrl Type	Name	Description
0x01	Protection Established	Signals that DTLS chunk protection has been enforced

Protection Established The Protection Established control message (Ctrl Type = 0x01) is sent by the Responder to the Initiator after the Responder has installed all keys and enforced DTLS chunk protection. This message carries no Control Data (the payload following the Ctrl Type byte is empty). Upon receiving this message, the Initiator enforces DTLS chunk protection and informs the ULP that the association is protected.

Key Derivation

Role Determination Role determination and method selection follow the procedure defined in Section 5.1 of . After the SCTP association is established, the key-management function retrieves from the SCTP stack's DTLS chunk API the assigned role (Initiator/client or Responder/server), the selected DTLS Key Management Method, and the downgrade prevention data (both endpoints' DTLS Key Management Parameters) used as input to key derivation.

Exporter Context DTLS Key Contexts are derived using the TLS Exporter as defined in Section 7.5 of . The exporter context is constructed as the concatenation of the following fields:

Field	Length	Value
Direction	1 byte	0x00 = Client, 0x01 = Server
Key role	1 byte	0x00 = primary/traffic, 0x01 = restart
Key type	1 byte	0x00 = Key, 0x01 = SN_KEY, 0x02 = IV
Initiator KM Param	variable	DTLS Key Management Parameter sent by the Initiator
Responder KM Param	variable	DTLS Key Management Parameter sent by the Responder

Each DTLS Key Management Parameter (Section 4.1 of ) is included as the sequence of bytes sent on the wire, including the parameter header and excluding padding. This construction ensures that any modification to the DTLS Key Management Parameter during the SCTP handshake (a downgrade attack) results in mismatched keys and association failure.

Exporter Labels A single TLS Exporter label is used to derive all keying material: The specific key material (direction, role, and type) is differentiated by the exporter context (). Each combination of Direction, Key role, and Key type values produces a distinct export, yielding 12 values in total (2 directions × 2 roles × 3 types). The Initiator (TLS client) installs exports with Direction=Client as its write keys and Direction=Server as its read keys. The Responder does the reverse. The length of exported material depends on the negotiated cipher suite.

DKC Installation Each successful TLS handshake produces two DKCs:

• A Primary DKC for regular SCTP traffic.
• A Restart DKC for the SCTP restart procedure.

The first DKC established for any SCTP association MUST use DTLS epoch 3. Each subsequent Primary DKC uses the next consecutive epoch. After an SCTP restart, the epoch resets to 3. The Restart DKC MUST be maintained in a well-defined state (initialized but never used for regular traffic) so that both endpoints have a consistent view of sequence numbers and replay window.

Procedures

Initial Establishment

Initial Establishment | |<---------------------[INIT-ACK]---------------------+ +--------------------[COOKIE ECHO]------------------->| 2. 3. |<--------------------[COOKIE ACK]--------------------+ | | | Key Manager Key Manager | | | | | 4. +--->| TLS START TLS START |<----+ | | | | | +---------[DATA(TLS Client Hello)]-------->| 5. | | | | 6. | | 8. |<-[DATA(TLS Server Hello ... Finished)]---+ 7. | | 9. +--[DATA(TLS Certificate ... Finished)]--->| 10. | | | | 11. | |13. |<--[DATA(Protection Established)]---------+ 12. | | | | | | | -. 14. +------------[DTLS CHUNK(DATA(APP DATA))]------------>| | APP DATA +<-----------[DTLS CHUNK(DATA(APP DATA))]-------------+ +--------- | ... | | ]]>

The diagram shows the case where SCTP Initiator is also resulting as Key Manager Client. The opposite case is identical but with inverted roles among Key Managers. In the following procedure we use Initiator and Responder referring to SCTP, Client and Server referring to Keymanager role, and implicitly TLS roles. The procedure is as follows:

1. The Initiator sends INIT containing the DTLS Key Management Parameter (Section 4.1 of ) with this method's identifier (see ) in its preference-ordered list.
2. The Responder enters ESTABLISHED state. It retrieves the agreed DTLS Key Management Method and role from the SCTP stack (e.g., using the "Get Agreed DTLS Key Management Method and Role" API defined in Section 7.2 of ) and verifies that the selected method matches the one defined in this document (see ) and gets the assigned role as key manager client or server (in the example depicted in it is server).
3. The Initiator enters ESTABLISHED state. It performs the same retrieval and verification as the Responder, confirming the assigned role as key manager client or server (in the example depicted in it is client).
4. The client key manager starts a TLS 1.3 handshake, limiting offered cipher suites to those supported by the DTLS Chunk Protection Operator, and sends TLS ClientHello per .
5. The server key manager receives the TLS ClientHello. If a HelloRetryRequest is needed, an additional round-trip occurs before proceeding.
6. The server key manager uses the TLS Exporter to derive the client key material for both the Primary and Restart DKCs and installs it as the read (receive) key material, per .
7. The server key manager sends its TLS ServerHello through Finished messages.
8. The client key manager receives the TLS ServerHello message, exports all Primary and Restart DKC keys, and installs the client key material as its write (send) key and the server key material as its read (receive) key.
9. The client key manager sends its TLS Certificate/CertificateVerify/Finished, protected by the DTLS Chunk using the new Primary DKC.
10. The server key manager decrypts the DTLS-chunk-protected TLS messages, completes the handshake, exports the server key material for both the Primary and Restart DKCs, and installs it as its write (send) key.
11. The server key manager calls Require Protected SCTP Packets to enforce DTLS chunk protection for all future packets and informs the ULP that the association is protected.
12. The server key manager sends a Protection Established control message () to the client key manager.
13. The client key manager receives the Protection Established control message, calls Require Protected SCTP Packets to enforce DTLS chunk protection for all future packets, and informs the ULP that the association is protected.
14. Application traffic can begin.

If the TLS handshake fails, the SCTP association MUST be aborted. After key installation, the TLS connection SHOULD be closed promptly.

Rekeying

Triggering Criteria Rekeying is triggered by implementation-configurable criteria, including:

• Time elapsed since last peer authentication.
• Volume of data transferred since last forward-secrecy rekeying.
• Approaching the cipher suite's AEAD usage limits.

Procedure

Rekeying Procedure | 2. | | 4. |<-[DATA(TLS Server Hello ... Finished)]--+ 3. | | 5. +--[DATA(TLS Certificate ... Finished)]-->| 6. | | | | (traffic transitions to epoch N+1 DKC) | | | | (after draining, remove epoch N DKC) | | | ]]>

The diagram shows the case where SCTP Initiator is also resulting as Key Manager Client. The opposite case is identical but with inverted roles among Key Managers. In the following procedure we use Initiator and Responder referring to SCTP, Client and Server referring TLS roles. The Key manager roles are only used to handle in the case both sides initiate a rekey simultanously, see . Either endpoint may initiate rekeying. The procedure is as follows:

1. The peer willing to rekey becomes the TLS client for this rekey procedure. It sends a TLS ClientHello in a key management message. TLS messages are carried inside DTLS chunks (the association is already protected).
2. The other peer becomes the TLS server for this rekey procedure. It receives and processes the ClientHello, exports the client key material for both the Primary and Restart DKCs, and installs it as its read (receive) key.
3. The server sends its TLS ServerHello through Finished messages to the client.
4. The client receives the TLS ServerHello message, exports all Primary and Restart DKC keys, and installs the client key material as its write (send) key and the server key material as its read (receive) key.
5. The client sends its TLS Certificate/CertificateVerify/Finished encrypted with the new keys and starts the drain timer to remove the old (epoch N) DKC. From now on the client uses new keys.
6. The server receives and verifies the Finished message, exports and installs the server key material for both the Primary and Restart DKCs as its write (send) key, and starts the drain timer to remove the old (epoch N) DKC. From now on the server uses new keys.

The new DKCs use epoch N+1 (where N is the current epoch). Both old (epoch N) and new (epoch N+1) DKCs coexist temporarily until the drain timer expires (see ). All rekeying MUST use ephemeral key exchange. TLS Key Update MUST NOT be used.

Drain Timer Considerations The drain timer determines how long old (epoch N) DKCs are retained after new (epoch N+1) DKCs have been activated. Its purpose is to allow in-flight packets protected with the old keys to be received and processed before those keys are removed. The drain timer value depends on whether the delivery of the final rekeying message has been confirmed:

• If delivery of the last rekeying message has been confirmed (e.g., through SCTP acknowledgment of the DATA chunk carrying the TLS Finished), the old DKC MAY be removed after a short drain timer. A value of 120 seconds (one Maximum Segment Lifetime) is RECOMMENDED in this case.
• If delivery has not been confirmed, the drain timer MUST be set to at least the SCTP association failure time (T_fail). This ensures that if the final rekeying message is lost and requires retransmission, the old DKC remains available for as long as SCTP continues retransmission attempts. If the association fails (i.e., SCTP declares the peer unreachable), the DKCs are removed as part of association teardown.

The SCTP association failure time depends on the Retransmission Timeout (RTO) and the maximum number of retransmissions (Association.Max.Retrans, as defined in ). With the default values from (RTO.Initial = 1s, RTO.Max = 60s, Association.Max.Retrans = 10), T_fail is approximately 303 seconds. Implementations SHOULD set the drain timer to at least T_fail when delivery of the final rekeying message has not been confirmed.

Simultaneous Rekey Resolution As either endpoint can initiate a TLS handshake at the same time, either endpoint may receive a TLS ClientHello when it has already sent its own. In this case, the ClientHello from the Initiator (the endpoint with the keymanager client role) SHALL be processed, and the other SHALL be dropped.

Key Transition State Machine This specification allows up to 2 Primary DKCs to be active at the same time. The following state machine governs the transition:

State Diagram for Rekeying | YOUNG | | +------->| +--------------------+ | | +----+----+ | | | | | | | | 2. Client Hello | 3. Aging event | | | from peer | | | V V | | +---------+ 4. Client H +---------+ 5. TLS H/S | | | REMOTE | tie-break | LOCAL | Timeout | | | OLD |<-------------+ AGED +-----+ | | +----+----+ +----+----+ | | | 7. Flush | | | | +-------------+ | | | 6. Server Hello | | | +------------------------+ | | | | | V V | +---------+ +---------+ | | LOCAL | | ABORT | | | OLD | | | | +-----+---+ +---------+ | 8. Flush | +----------------+ ]]>

INIT:

Initial state. Only event 1 (TLS handshake completed) transitions to YOUNG.

YOUNG:

Only the Current DKC is populated. Event 2 (peer ClientHello) transitions to REMOTE OLD; event 3 (aging) transitions to LOCAL AGED.

LOCAL AGED:

A supervision timer runs. Event 5 (timeout) causes the key manager to check for local aging expire, in that case ABORT otherwise return to YOUNG. Event 4 (peer ClientHello with tie-break yielding server role) transitions to REMOTE OLD. Event 6 (ServerHello received) transitions to LOCAL OLD.

REMOTE OLD:

Both Old and Current DKCs exist. Old DKC is used for sending until the first packet encrypted with Current DKC is received from the peer. Event 7 (flush timer expires) transitions to YOUNG.

LOCAL OLD:

Both Old and Current DKCs exist. Current DKC is used for sending. Event 8 (flush timer expires) transitions to YOUNG.

In REMOTE OLD and LOCAL OLD, if a new ClientHello or Aging event arrives, the flushing timer is cleared and behavior is as in YOUNG.

SCTP Association Restart

Prerequisites For protected SCTP restart to succeed:

• Both endpoints MUST have a valid Restart DKC.
• The Restart DKC MUST be stored securely and persistently to survive crash events (see Section 10.4 of ).
• Both endpoints MUST have indicated restart support (R bit) in the DTLS Key Management Parameter.

Restart Procedure

SCTP Restart Procedure | | Plain 3. |<---------------------(INIT-ACK)--------------------+ +------- | | -' | | -. 4. +-------------[DTLS CHUNK(COOKIE ECHO)]------------->| | Protected 5. |<------------[DTLS CHUNK(COOKIE ACK)]---------------+ +---------- 6. | | -' 7. | | | (TLS handshake for new keys, steps 8-13) | | | 15. |<----------[DATA(Protection Established)]-----------+ 14. 16. | | 17. +------------[DTLS CHUNK(DATA(APP DATA))]----------->| APP DATA +<-----------[DTLS CHUNK(DATA(APP DATA))]------------+ | | ]]>

1. The restarting endpoint (Initiator) retrieves the restart key material from persistent secure storage and installs the Restart DKC for both send and receive directions.
2. The Initiator sends INIT (VTag=0).
3. The Responder replies INIT-ACK in plain text per . Both include the DTLS Key Management Parameter with the same method list but a new random Tie Breaker.
4. The Initiator sends COOKIE ECHO in a DTLS chunk protected with the Restart DKC (R bit set).
5. The Responder replies COOKIE ACK in a DTLS chunk protected with the Restart DKC.
6. Both endpoints have a new established association. Each endpoint immediately calls Require Protected SCTP Packets to enforce DTLS chunk protection (using the Restart DKC), then retrieves the agreed DTLS Key Management Method and role from the SCTP stack (e.g., using the "Get Agreed DTLS Key Management Method and Role" API defined in Section 7.2 of ) and verifies that the selected method matches the one defined in this document (see ) and that the assigned role is as expected.
7. The ULP MAY be informed that the association is protected at this point. ULP traffic MAY begin immediately using the Restart DKC.
8. The client key manager starts a TLS 1.3 handshake, limiting offered cipher suites to those supported by the DTLS Chunk Protection Operator, and sends TLS ClientHello per , protected by the Restart DKC.
9. The server key manager receives the TLS ClientHello, exports the client key material for the Primary DKC, and installs it as its read (receive) key.
10. The server key manager sends its TLS ServerHello through Finished messages.
11. The client key manager receives the TLS ServerHello message, exports all Primary DKC keys, and installs the client key material as its write (send) key and the server key material as its read (receive) key for the Primary DKC.
12. The client key manager sends its TLS Certificate/CertificateVerify/Finished, protected by the DTLS Chunk using the new Primary DKC.
13. The server key manager decrypts the DTLS-chunk-protected TLS messages, completes the handshake, exports the server key material for the Primary DKC, and installs it as its write (send) key.
14. The server key manager sends a Protection Established control message () to the client key manager. The server endpoint export and install the new Restart DKC key material (both send and receive directions), remove the old Restart DKC, and commit the new Restart DKC to persistent secure storage.
15. The client key manager receives the Protection Established control message.
16. The client key manager export and install the new Restart DKC key material (both send and receive directions), remove the old Restart DKC, and commit the new Restart DKC to persistent secure storage.
17. Application traffic uses to the new Primary DKC.

After restart, the new Primary DKC MUST use epoch 3 (the epoch resets). The Responder MUST NOT change the Restart DKC during the restart procedure. After the new Restart DKC is installed, the old one is removed. It is RECOMMENDED to complete the TLS handshake and install new DKCs as soon as possible after restart, to minimize the window during which no Restart DKC is available for a subsequent restart. Note: There MAY exist a short time gap after association establishment where no Restart DKC is yet installed. If an SCTP restart is initiated during that time, it will fail. However, this is unlikely as the restarting endpoint sends INIT multiple times with exponential back-off.

Error Handling TLS has its own error reporting via TLS alert messages. When a TLS handshake error occurs, the TLS alert is sent in an SCTP user message (see ) with the DTLS Key Management Messages PPID (4242). If a TLS handshake fails during initial establishment, the SCTP association MUST be aborted. If a TLS handshake fails during rekeying, and the current DKC has not yet reached its usage limits, the implementation SHOULD retry the handshake. If retry is not possible or the current DKC is aged beyond policy limits, the association MUST be aborted.

Security Considerations

General The security considerations given in , , and also apply to this document. BCP 195 provides recommendations and requirements for improving the security of deployed services that use TLS. BCP 195 MUST be followed.

Privacy Considerations Although TLS for DTLS in SCTP provides privacy for user messages and almost all SCTP chunks, the SCTP common header, DTLS chunk header, and DTLS record header are not confidentiality protected. An attacker can correlate TLS connections over the same SCTP association using the SCTP common header. To provide identity protection, it is RECOMMENDED to use certificate-based authentication in TLS 1.3 and to not reuse tickets. TLS 1.3 with external PSK authentication does not provide identity protection. By mandating ephemeral key exchange and cipher suites with confidentiality, TLS for DTLS in SCTP effectively mitigates many forms of passive pervasive monitoring. Frequent rekeying forces attackers to perform dynamic key exfiltration and limits the amount of compromised data due to key compromise.

IANA Considerations

DTLS Key Management Method Identifier IANA is requested to assign one DTLS Key Management Method Identifier in the "DTLS Key Management Method" registry defined by to identify the key-management method defined in this document. DTLS Key Management Method Identifier

Identifier	Key Management Method Name	Reference	Contact
192	TLS for DTLS in SCTP	RFC-TBD	Draft Authors

TLS Exporter Labels IANA is requested to register the following value in the TLS Exporter Label Registry with Reference RFC-TBD and empty Comment. TLS Exporter Label

Value	DTLS-OK	Recommended
EXPORTER_TLS_FOR_DTLS_IN_SCTP	Y	N

References Normative References This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. This document formally deprecates Transport Layer Security (TLS) versions 1.0 (RFC 2246) and 1.1 (RFC 4346). Accordingly, those documents have been moved to Historic status. These versions lack support for current and recommended cryptographic algorithms and mechanisms, and various government and industry profiles of applications using TLS now mandate avoiding these old TLS versions. TLS version 1.2 became the recommended version for IETF protocols in 2008 (subsequently being obsoleted by TLS version 1.3 in 2018), providing sufficient time to transition away from older versions. Removing support for older versions from implementations reduces the attack surface, reduces opportunity for misconfiguration, and streamlines library and product maintenance. This document also deprecates Datagram TLS (DTLS) version 1.0 (RFC 4347) but not DTLS version 1.2, and there is no DTLS version 1.1. This document updates many RFCs that normatively refer to TLS version 1.0 or TLS version 1.1, as described herein. This document also updates the best practices for TLS usage in RFC 7525; hence, it is part of BCP 195. This document specifies version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The DTLS 1.3 protocol is based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of order protection / non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document obsoletes RFC 6347. This document describes the Stream Control Transmission Protocol (SCTP) and obsoletes RFC 4960. It incorporates the specification of the chunk flags registry from RFC 6096 and the specification of the I bit of DATA chunks from RFC 7053. Therefore, RFCs 6096 and 7053 are also obsoleted by this document. In addition, RFCs 4460 and 8540, which describe errata for SCTP, are obsoleted by this document. SCTP was originally designed to transport Public Switched Telephone Network (PSTN) signaling messages over IP networks. It is also suited to be used for other applications, for example, WebRTC. SCTP is a reliable transport protocol operating on top of a connectionless packet network, such as IP. It offers the following services to its users: The design of SCTP includes appropriate congestion avoidance behavior and resistance to flooding and masquerade attacks. Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are used to protect data exchanged over a wide range of application protocols and can also form the basis for secure transport protocols. Over the years, the industry has witnessed several serious attacks on TLS and DTLS, including attacks on the most commonly used cipher suites and their modes of operation. This document provides the latest recommendations for ensuring the security of deployed services that use TLS and DTLS. These recommendations are applicable to the majority of use cases. RFC 7525, an earlier version of the TLS recommendations, was published when the industry was transitioning to TLS 1.2. Years later, this transition is largely complete, and TLS 1.3 is widely available. This document updates the guidance given the new environment and obsoletes RFC 7525. In addition, this document updates RFCs 5288 and 6066 in view of recent attacks. This document describes a method for adding Datagram Transport Layer Security (DTLS) based authentication and cryptographic protection to the Stream Control Transmission Protocol (SCTP). This SCTP extension is intended to enable communication privacy for applications that use SCTP as their transport protocol and allows applications to communicate in a way that is designed to prevent eavesdropping and detect tampering or message forgery. Once enabled, this also applies to the SCTP payload as well as the SCTP control information. Applications using this SCTP extension can use most of the transport features provided by SCTP and its other extensions. The use of the SCTP Authentication extension defined in RFC 4895 is incompatible with the extension defined in this document but would not provide any additional service. This implies that the Dynamic Address Reconfiguration as specified in RFC 5061 can only be used as described in this document. This document obsoletes RFC 6083 and updates RFC 5061. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References A number of protocols wish to leverage Transport Layer Security (TLS) to perform key establishment but then use some of the keying material for their own purposes. This document describes a general mechanism for allowing that. [STANDARDS-TRACK] Many application technologies enable secure communication between two entities by means of Transport Layer Security (TLS) with Internet Public Key Infrastructure using X.509 (PKIX) certificates. This document specifies procedures for representing and verifying the identity of application services in such interactions. This document obsoletes RFC 6125.