Re: [tsvwg] 3GPP SA3 reply LS on SCTP-AUTH and DTLS

Michael Tuexen <> Wed, 31 May 2023 20:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E3158C15155F for <>; Wed, 31 May 2023 13:05:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.596
X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wfa-rffzcFPg for <>; Wed, 31 May 2023 13:05:48 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 16D17C15198D for <>; Wed, 31 May 2023 13:05:46 -0700 (PDT)
Received: from (unknown [IPv6:2a02:8109:1140:c3d:e422:dc49:497b:89]) (Authenticated sender: lurchi) by (Postfix) with ESMTPSA id A72F571A5AF9E; Wed, 31 May 2023 22:05:41 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\))
From: Michael Tuexen <>
In-Reply-To: <>
Date: Wed, 31 May 2023 22:05:40 +0200
Cc: "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: John Mattsson <>
X-Mailer: Apple Mail (2.3731.600.7)
Archived-At: <>
Subject: Re: [tsvwg] 3GPP SA3 reply LS on SCTP-AUTH and DTLS
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 31 May 2023 20:05:53 -0000

> On 31. May 2023, at 20:19, John Mattsson <> wrote:
> Hi Michael,
> >Where you able to also get some feedback related to the questions I raised in my e-mail sent on May 14th?
> I was not there myself. But I would assume that 3GPP did not discuss more than the information in the LS and in the drafts. Your questions are certainly relevant, but the security group might not be the right working group to ask some of your questions. 
> Magnus and Michael wrote:
> >> Much lower requirements on DTLS implementations when it comes to support of functionality
> >Which is the other way around at the SCTP level.
> Not having to make any changes to the DTLS library is very important from a security standpoint. Changes to the DTLS library can easily introduce security vulnerabilities and having changes makes it much harder to quickly apply security patches.
Which DTLS implementation can be used without any changes to implement DTLS in SCTP?
In particular for a kernel SCTP stack. If the WG wants to go down that implementation
specific path, we need to focus on one.

Best regards
> Cheers,
> John
> From: Michael Tuexen <>
> Date: Wednesday, 31 May 2023 at 16:04
> To: John Mattsson <>
> Cc: <>
> Subject: Re: [tsvwg] 3GPP SA3 reply LS on SCTP-AUTH and DTLS
> > On 30. May 2023, at 17:54, John Mattsson <> wrote:
> > 
> > Hi,
> > 3GPP SA3 (Security) had a meeting last week and sent a Reply LS to TSVWG regarding SCTP-AUTH and DTLS. The LS will appear in the IETF LS tracker at a later date when the 3GPP and IETF secretariats has processed the LS.
> >
> > SA3 discussed the discovered vulnerabilities, DTLS over SCTP, DTLS in SCTP, the importance of this work, and agreed on the following text:
> > "SA3 would like to thank IETF Transport Area Working Group (TSVWG) for notifying SA3 of the vulnerabilities related to SCTP-AUTH and DTLS over SCTP.
> > SA3 agrees that the vulnerabilities are serious – they are affecting confidentiality, integrity, replay, and availability. Supporting DTLS over SCTP in N2, Xn, F1, and E1 interfaces has been made mandatory from Release 15 onwards. Therefore, SA3’s understanding is that it is important to solve all the security vulnerabilities, including the availability vulnerabilities. Since the problem is related to the use of DTLS with SCTP, SA3’s understanding is that the solution should be based on DTLS, and the solution should not rely on unsupported DTLS features.
> > SA3 kindly asks TSVWG to work on and publish a solution as soon as possible."
> Hi John,
> thanks for the information. Where you able to also get some feedback related to the questions
> I raised in my e-mail sent on May 14th?
> > We need to progress the work in TSVWG fulfilling 3GPP requirements of fixing the availability vulnerabilities, not relying on unsupported DTLS features, and to publish a solution as soon as possible. DTLS in SCTP seems like the only solution as it solves the availability vulnerabilities and do not rely on unsupported DTLS features.
> This conclusion is not clear to me. It highly depends on the architecture of the SCTP you are using.
> Therefore, my questions above. However, up to know we have not made any particular requirements on
> whether you use a userland or kernel SCTP stack. We just specified a socket API and ensured that
> you can implement it in kernel land. Implementing it in userland is then not a problem.
> Best regards
> Michael
> > Cheers,
> > John