From nobody Wed May 31 13:05:54 2023 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3158C15155F for ; Wed, 31 May 2023 13:05:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: 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 mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wfa-rffzcFPg for ; Wed, 31 May 2023 13:05:48 -0700 (PDT) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16D17C15198D for ; Wed, 31 May 2023 13:05:46 -0700 (PDT) Received: from smtpclient.apple (unknown [IPv6:2a02:8109:1140:c3d:e422:dc49:497b:89]) (Authenticated sender: lurchi) by mail-n.franken.de (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: "tsvwg@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <787FAEF3-5F3C-466E-AEB6-CF0E1938F9D7@lurchi.franken.de> 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-BeenThere: tsvwg@ietf.org 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: >=20 > Hi Michael, >=20 > >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.=20 > 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 Michael >=20 > Cheers, > John >=20 > From: Michael Tuexen > Date: Wednesday, 31 May 2023 at 16:04 > To: John Mattsson > Cc: tsvwg@ietf.org > Subject: Re: [tsvwg] 3GPP SA3 reply LS on SCTP-AUTH and DTLS > > On 30. May 2023, at 17:54, John Mattsson = wrote: > >=20 > > 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. > > = https://protect2.fireeye.com/v1/url?k=3D31323334-501d5122-313273af-4544455= 55731-e80a50d8b7f2c96c&q=3D1&e=3D910c8519-cb03-46e1-a414-afc589ed9d3f&u=3D= https%3A%2F%2Fwww.3gpp.org%2Fftp%2Ftsg_sa%2FWG3_Security%2FTSGS3_111_Berli= n%2FDocs%2FS3-233355.zip > > 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 =E2=80=93 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=E2=80=99s = 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=E2=80=99s = 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, >=20 > 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. >=20 > Best regards > Michael > > Cheers, > > John