From michael.tuexen@lurchi.franken.de Tue Mar 26 07:44:24 2024 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 E180FC14F6A9 for ; Tue, 26 Mar 2024 07:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_PERMERROR=0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable 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 2CoNs95bpLhe for ; Tue, 26 Mar 2024 07:44:21 -0700 (PDT) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE5B3C14F69A for ; Tue, 26 Mar 2024 07:44:18 -0700 (PDT) Received: from smtpclient.apple (unknown [194.94.6.45]) (Authenticated sender: lurchi) by mail-n.franken.de (Postfix) with ESMTPSA id 935B6721E280D; Tue, 26 Mar 2024 15:44:12 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\)) From: Michael Tuexen In-Reply-To: Date: Tue, 26 Mar 2024 15:44:12 +0100 Cc: Marcelo Ricardo Leitner , tsvwg IETF list , Magnus Westerlund Content-Transfer-Encoding: quoted-printable Message-Id: <828FD33D-E4C0-4E16-BA61-FEB962A41BA1@lurchi.franken.de> References: <54EF29EA-B0B4-43E8-A930-B209C99545A5@lurchi.franken.de> To: Claudio Porfiri X-Mailer: Apple Mail (2.3774.500.171.1.1) Archived-At: Subject: Re: [tsvwg] DTLS for SCTP: DTLS Chunk kernel part testing 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: Tue, 26 Mar 2024 14:44:25 -0000 > On 26. Mar 2024, at 14:14, Claudio Porfiri = wrote: >=20 > Hi Marcelo, > Thanks for the information. > I am not aware of an Ericsson proposal that requires changes in DTLS. > The alternative A did need features in DTLS that are part of DTLS1.2 = but never implemented by OpenSSL or others, the alternative B doesn't = need any change in the DTLS stack. Really? Aren't you assuming an SCTP userland stack? I don't see how a an unmodified DTLS stack can be used in combination with an SCTP kernel stack. Could you elaborate? Best regards Michael >=20 > Best regards, > Claudio. >=20 > -----Original Message----- > From: tsvwg On Behalf Of Michael Tuexen > Sent: Tuesday, March 26, 2024 2:06 PM > To: Marcelo Ricardo Leitner > Cc: Magnus Westerlund ; tsvwg IETF = list > Subject: Re: [tsvwg] DTLS for SCTP: DTLS Chunk kernel part testing >=20 >> On 22. Mar 2024, at 22:27, Marcelo Ricardo Leitner = wrote: >>=20 >> Hi, >>=20 >> On Mon, Mar 18, 2024 at 12:08:10PM +0100, Michael Tuexen wrote: >>>> On 18. Mar 2024, at 08:58, Magnus Westerlund = wrote: >>>>=20 >>>> Thanks Michael, >>>> I think your answer below makes it clear that it is possible to get = DTLS chunk parties implemented in an open source operating system. I do = understand the personal angle. I hope when the patent application = becomes public before June the WG members will >>> Please understand what is formally possible might be different from = what people >>> feel comfortable with. I think that the reservation I expressed is = shared by >>> Marcelo, who is one of the Linux maintainers. >>=20 >> Exactly, Michael. Magnus, please consider that Linux (and FreeBSD) = are >> Open Source software, which are known to dislike licensed code for >> many reasons. Even though the suggestion could fit technically, what >> it essentially does is (with my upstream maintainer hat on) give = me/us >> maintainers more work, to maintain this additional code, that only >> those willing to pay you can use. So thanks but no, I'm not = interested >> in finding hacky ways to (partially?) test code that the majority of >> the users cannot benefit from. >>=20 >> I hope that the WG realizes the problem that this represents before = it >> is too late, otherwise we may never support DTLS over SCTP in the >> Linux kernel. > Dear all, >=20 > Martin asked at the TSVWG@IETF119 meeting what the position of the = OpenSSL > project is on having IPR protected code in their code base. >=20 > I contacted Matt Caswell and got the following response: >=20 > The OpenSSL contains: >=20 > 3. Grant of Patent License. Subject to the terms and conditions of > this License, each Contributor hereby grants to You a perpetual, > worldwide, non-exclusive, no-charge, royalty-free, irrevocable > (except as stated in this section) patent license to make, have = made, > use, offer to sell, sell, import, and otherwise transfer the = Work, > where such license applies only to those patent claims licensable > by such Contributor that are necessarily infringed by their > Contribution(s) alone or by combination of their Contribution(s) > with the Work to which such Contribution(s) was submitted. If You > institute patent litigation against any entity (including a > cross-claim or counterclaim in a lawsuit) alleging that the Work > or a Contribution incorporated within the Work constitutes direct > or contributory patent infringement, then any patent licenses > granted to You under this License for that Work shall terminate > as of the date such litigation is filed. >=20 > and someone contributing the the code base must sign a CLA which = contains: >=20 > 3. Grant of Patent License. Subject to the terms and conditions of = this Agreement, You hereby grant to the Foundation and to recipients of = software distributed by the Foundation a perpetual, worldwide, = non-exclusive, no-charge, royalty-free, irrevocable (except as stated in = this section) patent license to make, have made, use, offer to sell, = sell, import, and otherwise transfer the Work, where such license = applies only to those patent claims licensable by You that are = necessarily infringed by Your Contribution(s) alone or by combination of = Your Contribution(s) with the Work to which such Contribution(s) was = submitted. If any entity institutes patent litigation against You or any = other entity (including a cross-claim or counterclaim in a lawsuit) = alleging that your Contribution, or the Work to which you have = contributed, constitutes direct or contributory patent infringement, = then any patent licenses granted to that entity under this Agreement for = that Contribution or Work shall terminate as of the date such litigation = is filed. >=20 > Therefore, the are two scenarios to distinguish: >=20 > 1. People from Ericsson will contribute the change to the OpenSSL = project. > 2. People not from Ericsson will contribute code changes to the = OpenSSL project. >=20 > The first case is simple: Then it is simple, since they grant the = patent license. > However, based on the communication up to now, I don't think this is = the plan > of the people affiliated with Ericsson and participating in the = discussion > right now. Magnus, please correct me, if I'm wrong. I also formulates = it in a > way that you don't have to speak for all of Ericsson, which might be = hard. >=20 > The second case is what seems to be more realistic. At least Hannes = wanted to > work on OpenSSL and I would look at that implementation also. However, = before > it would be accepted by the OpenSSL team, they need to think about an = exception > and they must basically be convinced they they have the patent = licenses they > need. I guess, based on the statements of the people from Ericsson in = the discussion, > that such a license would not be granted. > =46rom a contributor point of view, I would not even start spending = cycles on an > implementation, when I would expect that it can not be accepted by the = OpenSSL > team. My guess is that, for example, Hannes shares the same view. >=20 > @Magnus: Again, please correct me if I stated anything in relation of = Ericsson > incorrectly. The above statement is intended to be based on facts. > Finally a discalimer: I'm not a lawyer... >=20 > Best regards > Michael >>=20 >> Best regards, >> Marcelo >>=20 >>>=20 >>> Best regards >>> Michael >>>> be able to analyze what the claimed IPR covers and what can be done = without requiring any licensing and when such is needed in relation to = different use cases where DTLS in SCTP would be useful security = mechanism. Cheers >>>> Magnus >>>> From: Michael Tuexen >>>> Date: Monday, 18 March 2024 at 17:18 >>>> To: Magnus Westerlund >>>> Cc: tsvwg IETF list >>>> Subject: Re: [tsvwg] DTLS for SCTP: DTLS Chunk kernel part testing >>>>> On 18. Mar 2024, at 00:04, Magnus Westerlund = wrote: >>>>>=20 >>>>> Hi, >>>>> In the design team we have discussion around barriers to implement = DTLS Chunk = (https://datatracker.ietf.org/doc/draft-westerlund-tsvwg-sctp-dtls-chunk/)= as part of SCTP stacks that are in open source OS kernels. The = discussion in the design team indicated that they could implement and = release the functionality described in the above draft. What was raised = as an issue was the testing of this code using the API that would exist = to the upper layer implementation that would implement the DTLS = handshakes and rekeying per: = https://datatracker.ietf.org/doc/draft-westerlund-tsvwg-sctp-dtls-handshak= e/. >>>>> Is there any reason why one cannot actually write code to test = this API without implementing almost any of = draft-westerlund-tsvwg-sctp-dtls-handshake? I would think the goal of = the kernel parts is to show that the lower layer and its API works and = can >>>> Hi Magnus, >>>>=20 >>>> this is my personal opinion with respect to implementing this in = FreeBSD. >>>> Of course, one can do what you suggest. When I would implement it, = most >>>> likely I would add support for it in packetdrill to do some = functional >>>> testing. I guess some fuzz testing with tools like syzkaller would = also >>>> be done. >>>> But when I'm implementing something (functionality in the kernel = and >>>> an API for it) which has mainly one use case, I would really prefer = to >>>> be able to test this in this use case. This is my personal = preference >>>> and nothing requires me to do this testing. But not testing it seem >>>> sub-optimal to me. >>>>=20 >>>> Best regards >>>> Michael >>>>> be used by a higher layer application on top of the SCTP stack. In = a test application one could use hard coded keys and have multiple sets = to test rekeying and not run DTLS handshakes at all between the = endpoints. >>>>> Cheers >>>>> Magnus >>>=20 >>>=20 >=20