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

["Charles Eckel (eckelcu)" <[e-mail]>]

Thanks Magnus. This looks good to me.

If the chairs and our AD agree, the next step is to repackage it as a 3GPP contribution. I know you are familiar with that, but I can do that if you like. Then I can post and send the LS with the contribution as an attachment.

Cheers,
Charles

On Nov 4, 2025, at 2:48 PM, Magnus Westerlund <magnus.westerlund=[e-mail]> wrote:

Thanks all for the feedback and suggestions. Having incorporated the feedback the resulting text is the following:


Draft LS from TSVWG to 3GPP RAN3 and SA3 on DTLS for SCTP

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) would like 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 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 supportingunlimited 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.


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,  <applewebdata://A17F102A-5941-4EFF-99A8-EA1E3610E230/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, 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/