Subject: [tsvwg] New Liaison Statement, "LS on DTLS for SCTP Progress Report"
From: Liaison Statement Management Tool <[email-masked]>
To: "3GPP Liaisons Coordinator" <[email-masked]>, "Peter Schmitt" <[email-masked]>
Cc: Gorry Fairhurst <[email-masked]>, Mike Bishop <[email-masked]>, Transport and Services Working Group Discussion List <[email-masked]>, [email-masked]
Date: Mon, 10 Nov 2025 18:14:32 -0800
List-Id: Transport Area Working Group <tsvwg.ietf.org>

Title: LS on DTLS for SCTP Progress Report
Submission Date: 2025-11-11
URL of the IETF Web page: https://datatracker.ietf.org/liaison/2076/

To: 3GPP TSG SA WG3, 3GPP TSG RAN WG3
From: Transport and Services Working Group (tsvwg)
Purpose: For information

Email Addresses
---------------
From: Charles Eckel <[email-masked]>
To: 3GPP Liaisons Coordinator <[email-masked]>, Peter Schmitt <[email-masked]>
Cc: Mike Bishop <[email-masked]>,Gorry Fairhurst <[email-masked]>,Zaheduzzaman Sarker <[email-masked]>,Charles Eckel <[email-masked]>,Transport and Services Working Group Discussion List <[email-masked]>,Martin Duke <[email-masked]>
Response Contacts: Martin Duke <[email-masked]>,Zaheduzzaman Sarker <[email-masked]>
Technical Contacts: 

Referenced liaison: Reply LS on DTLS for SCTP (https://datatracker.ietf.org/liaison/1854/)

Referenced liaison: Reply LS on DTLS for SCTP next steps and request for input (https://datatracker.ietf.org/liaison/1858/)

Body: 1. Description

IETF’s Transport Working Group (TSVWG) would like to inform 3GPP’s RAN3 and SA3 WGs
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 now adopted two new WG items to provide a technical solution to address the maximum message size issue with SCTP and DTLS as observed in [2]. 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 initiates the negotiation using SCTP parameters and 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 being encrypted and authenticated. It also ensures that there is no limit on application message sizes as they are fragmented by the regular SCTP mechanism, thereby 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 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 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 aims 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, has dependency on the TLS extended key-update mechanism [7], hence work needs to be done in both TSVWG and TLS working groups.

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 welcomes any feedback on its work items.

2. Upcoming Meeting

IETF 125 14-20 March 2026, Shenzhen, China
IETF 126 18-24 July 2026, Vienna, Austria

3. 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] Stream Control Transmission Protocol (SCTP) DTLS Chunk, https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-dtls-chunk/

[5] Using Datagram Transport Layer Security (DTLS) for Key Management for the Stream Control Transmission Protocol (SCTP) DTLS Chunk, 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, https://datatracker.ietf.org/doc/draft-ietf-tls-extended-key-update/

[8] Datagram Transport Layer Security (DTLS) based key-management of the Stream Control Transmission Protocol (SCTP) DTLS Chunk, https://datatracker.ietf.org/doc/draft-westerlund-tsvwg-sctp-dtls-handshake/
Attachments:

    LS on DTLS for SCTP Progress Report
    https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2025-11-11-tsvwg-3gpp-tsg-sa-wg3-3gpp-tsg-ran-wg3-ls-on-dtls-for-sctp-progress-report-attachment-1.pdf