[tsvwg] Proposed Liaison statement on DTLS for SCTP from TSVWG to 3GPP RAN3 and SA3

[Magnus Westerlund <[e-mail]>]

TSVWG,

Below is a proposed liaison statement from TSVWG to 3GPP RAN3 and SA3 on DTLS for SCTP.
It would be desirable to send this LS before the end of the week. If you have any feedback on the LS please comment.

/Magnus

Title: IETF TSVWG’s DTLS for SCTP Progress Report
From: IETF TSVWG
To: 3GPP-TSG-RAN-WG3, 3GPP-TSG-SA-WG3
To Contacts: Peter Schmitt <[e-mail]<mailto:[e-mail]>>
Susanna Kooistra <[e-mail]<mailto:[e-mail]>>
Cc: Transport Area Working Group Discussion List <[e-mail]<mailto:[e-mail]>>
Gorry Fairhurst <[e-mail]<mailto:[e-mail]>>

Purpose: For Information

Body:

IETF’s Transport Working Group (TSVWG) likes to inform 3GPP’s RAN3 and SA3 WG about its progress on defining a DTLS based security solution for SCTP that has occurred since the previous exchange of liaison statements [1,2,3].

TSVWG has finally agreed after extended deliberations on a technical direction and have adopted two new WG items for this new direction. The complete solution consists of two separate components.

The first component, which is the core of the complete solution, is called the DTLS Chunk. This component specifies how an SCTP endpoint initiate the negotiation using SCTP parameters, protects its packets using DTLS records using key-contexts that have been provisioned using an API to the SCTP stack. This protects the content of each SCTP packet in its own DTLS record. This results in all application messages as well as SCTP control chunks are encrypted and authenticated. It also ensures that there is no limit on application message sizes as they are fragmented by the regular SCTP mechanism supporting unlimited message size. This component is defined in the TSVWG adopted internet draft “Stream Control Transmission Protocol (SCTP) DTLS Chunk” [4]. The draft also defines certain requirements on key-management to prevent down-grade attacks.

The second component of the complete solution is a key-management specification that can provision the DTLS chunk (i.e., the first component) with keys. Such a key-management is defined as a functionality on top of the SCTP association, using an API defined in the DTLS chunk [4] to provision keys to secure the communication. TSVWG has adopted an Internet draft defining such a key-management titled: “Using Datagram Transport Layer Security (DTLS) for Key Management for the Stream Control Transmission Protocol (SCTP) DTLS Chunk” [5]. This key-management is dependent on a new TLS 1.3 [6] functionality  — the extended key-update [7] being defined by the TLS WG. It will support long lived sessions through ephemeral rekeying ensuring forward secrecy and also supports SCTP Association restart.

Splitting the solution into two components (i.e., the DTLS chunk and the key-management) allows for alternative key-management to be specified if desired to achieve certain properties. There exists an individual internet draft detailing an alternative key-management [8], which can be seen as a proof that this divided concept works.

TSVWG targets to have the DTLS chunk, the first component, published as RFC before the end of 2026. The WG key-management specification [5], the second component, is being worked on as fast as possible. However, due to the dependency on the TLS extended key-update mechanism [7], which is also under specification and requires formal analysis, it is currently difficult to estimate an approximate completion date for the second component.

TSVWG would like to inform 3GPP RAN3, following their previous observations in [2], that this technical solution does not limit the maximum size of application protocol messages.

TSVWG plans to inform 3GPP RAN3 and SA3 when each of the components have been requested to be published. TSVWG welcome any feedback on its work items.


References:
[1] TSVWG LS to RAN3 and SA3: DTLS for SCTP next steps and request for input, https://datatracker.ietf.org/liaison/1851/
[2] R3-234497 - Reply LS on DTLS for SCTP next steps and request for input, https://datatracker.ietf.org/liaison/1858/
[3] S3-234160 - Reply LS on DTLS for SCTP, https://datatracker.ietf.org/liaison/1854/
[4]   draft-ietf-tsvwg-sctp-dtls-chunk-01<https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-dtls-chunk/>, https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-dtls-chunk/
[5] draft-ietf-tsvwg-dtls-chunk-key-management-00,  <applewebdata://F3B41817-5CB9-459A-980F-E37192BF4819/draft-ietf-tsvwg-dtls-chunk-key-management-00,%20%20> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-dtls-chunk-key-management/
[6] The Transport Layer Security (TLS) Protocol Version 1.3, RFC 8446, Aug 2018, https://datatracker.ietf.org/doc/rfc8446/
[7] Extended Key Update for Transport Layer Security (TLS) 1.3, draft-ietf-tls-extended-key-update-06, Oct 2025,  <https://datatracker.ietf.org/doc/draft-ietf-tls-extended-key-update/>  https://datatracker.ietf.org/doc/draft-ietf-tls-extended-key-update/
[8]  draft-westerlund-tsvwg-sctp-dtls-handshake-05 <https://datatracker.ietf.org/doc/draft-westerlund-tsvwg-sctp-dtls-handshake/> , https://datatracker.ietf.org/doc/draft-westerlund-tsvwg-sctp-dtls-handshake/