Session Date/Time: 21 Jul 2026 07:00
[00:01:33] Tero Kivinen: Alright. I think it's 09:00. I'm still having problems with my laptop, but it doesn't matter. We can start. I have a co chair who can actually take care of this. So this is IPsecME working group and I'm.
[00:01:49] Valery Smyslov: I'm a coach of you.
[00:01:51] Tero Kivinen: Here. So this is the note well. Note as well. There's a QR code that you can read or check out and read the there's more stuff there. Alright. So if you have a next slide. So it will be useful to have a notetakers. And, yes, we I think we do still need notetakers. Volunteers? Alright. There we have one. I haven't actually done the, you know, the baseline in there yet in the the the whatever it is called to stand the interpad. It used to be interpad, but now it's a hedge for for some whatever. But use the notetaker tool in the other people are gonna go and help, especially those who have questions, go there and check out that your questions are properly, you know, write written down because sometimes people ask long questions and it's not clear what they are asking in the beginning. Alright. So there are other links. So if you go forward, the next slide. So there here's our agenda. I did have a new, though, original miscalculation of the times, so I had five ten minutes to act too long, but I also didn't receive, you know, slides for the last presentation in on time. And so that actually solved that issue. Does anybody have any agenda bashing that they would do or like to do? If not, then let's go forward. The next one is we we haven't published any RFCs since last IETF, and we don't have anything in the RFC editor out for the eight queue, but we have two in RFC editor queue now. So the post quantum key extends with ML-KEM and the, you know, downgrade prevention draft are drafts are now in the RFC editor queue. And we have one that is in public case requested, which is p c post quantum out in case. Alright. Paul has some questions, I guess.
[00:03:55] Paul Wouters: Sorry. Paul about this. I'm looking if the AD is in the room or not. I I was looking if the AD was in the room, but apparently, they're not here yet.
[00:04:02] Tero Kivinen: AD is not here because she said that we should do all the stuff that needs requires her before.
[00:04:09] Paul Wouters: Anyway, so during during the discussion on ML-KEM on the TLS list, if you read all thousand plus messages, there was a line that they're going to add about the PRNG, and I think they wanted this document to have that same line to avoid other big discussions and unequal treatments. So we might have to keep the document on hold to just add that one city line about PRNG.
[00:04:36] Tero Kivinen: So what what which which document was it? It was this
[00:04:40] Paul Wouters: The ML the ML-KEM document.
[00:04:42] Tero Kivinen: ML-KEM. The base ML-KEM. Okay. Yep. Oh, yeah. There was there was this one word, but it I I my understanding was what they've talked about fixing that in out '48.
[00:04:53] Paul Wouters: Yes. Yes. That's fine. But I'm just reminding you Yep. That you know that you should do this.
[00:04:58] Tero Kivinen: Yeah. No. It's out of out of the working group already. Alright. So next page is our, you know we don't have anything for the eighties to oh, sorry. To to separate the write up. That's funny. Usually, we have set plenty of there. We have three documents that are now through the working group last call. There's reliable transport. There is an, you know, diet two diet SPSP stuff, and, Daniel, is who's here? See, he was he sent an email yesterday about those, and I think they should be ready to go now forward. They were waiting for one more draft, and then they should be now done. Alright. And I guess we are going to be having a couple of documents here calling the working group last calls. And here is the in process working and one on one that is waiting for the working group adoption call. I will start that one immediately after this meeting. Alright. So then we go to the presentations, I guess. Does anybody have any comments about that? Any of these, you know, drafts or current stuff? Alright. The next one is the first presentation then. So Ben Seltz. K. My laptop stopped working. Yeah. Can you pass the clicker to that? Like, start working very soon, I can't do it yet because my laptop was starts.
[00:06:42] Chairperson: It's not horrible.
[00:06:43] Tero Kivinen: No. No. It's probably just because. Yes.
[00:06:46] Ben Seltz: Super. Good. Okay. I will be quick because we are short on the agenda time. This is the draft that specifies the use of SHA three and SHA three derivatives like KMAC in IKE and IPsec. So the main change since the last time we did this was we have simplified the PRF plus construction in this draft. So normally PRF plus calls PRF iteratively to generate as much new material as needed. Because KMAC is an extensible output function, we don't need to do this. We can just pass the values and the length required directly into KMAC, and it will automatically generate all the keys we need. This simplifies the design. It's a of an optimization. We quite like it. This also aligns with this other draft here, this draft-ikev2 PRF plus, which is a way of doing this for a generic variable length KDF. However, this does change one thing. It does open a little bit of a can of worms in that we now have this case where PRF plus and PRF, given the same inputs, will give the same output. So these are two different cryptographic functions that are invoked in different contexts, but they will now give the same same outputs given the same inputs. This is a change from Vanilla IKEv2 because in Vanilla IKEv2, when you call PRF plus, you because you iteratively call PRF, you essentially concatenate an iteration count to the end of one of the arguments, and that's no longer the case. This is the sort of thing that can maybe give cryptographers the cryptographic heebie jeebies. And one way you can alleviate this immediately is to use customization strings. So KMAC supports a customization string input, and this will bind the output to the context in which k mac is invoked. So we've defined four constant strings here for the different different context in which we're invoking k mac in this draft. So the reasons to do this, so it provides domain separation. There's there's no possibility of any of these cross context attacks, we believe, when you use these customization strings. We think by using the the customization string input, it makes it very easy to analyze in a tool like Tamarind. We haven't actually done that analysis, but we think that it will be easy to rule out these attacks using a a tool like Tamarind. And because the strings are fixed, it's not a not a a a varying customization string field. It's just a four fixed strings. It should be easy to implement. That said, there are engineering reasons why you might not wanna do this. So it might require a change to the the core of existing IPsec implementation. So not just the crypto bit, but also the bit where the crypto is invoked because there's a new a new API to to to pass in this customization string. And people might not wanna do this. I don't know. And it might also be the case that future extensible output functions have different APIs that don't support customization strings, so defining this unilaterally across all future variable length PRFs might not be possible. So there's a few different approaches we could take here. So we could unilaterally say no customization strings and just deal with that. We could specify the use of customization strings on a per algorithm basis. So we specify the K MAC, but not in the generic sense. We could specify their use in all algorithms that support them. So we would do that in the generic variable length PRF draft. If you want to go really crazy, you could do something like defining a wrapper around existing PRFs and and pass the customization string into those. That seems like a bad idea. It would be back backwards compatible, but it is technically an option. Or you could do something else entirely. One thing I note I said earlier was that the we've removed essentially the iteration count from PRF plus, and you could maybe just add that back in. That might provide sufficient domain separation. So I want people to discuss this. I'm going to send an email to the IPsec mailing list now. There we go. That's sent. By the time I sit back down, that should have arrived. Please discuss this on the mailing list, and if you have opinions, please reply. I don't know how much time I have,
[00:10:42] Chairperson: but there are three people in the queue.
[00:10:44] Tero Kivinen: Let's take your questions very quick.
[00:10:47] Sophie Schmidt: Just very quick, Sophie Schmidt, Google, I would not be worried about future XOFs not having customization strings. Customization strings are just a string that you put into the XOF and concatenate with the rest of
[00:10:59] Valery Smyslov: your
[00:10:59] Sophie Schmidt: input. These will always be there. Cryptographers love domain separators. I I would, if anything, expect future x of have more domain separator inputs rather than less. Okay.
[00:11:11] Chairperson: Thank you.
[00:11:12] Valery Smyslov: Alright. So I think that this customization string issue must be result in draft for the generic case. Mhmm. So I strongly support discussion on the list so that and encourage people to express their opinion because the draft is really stuck because this is the only issue. So once this issue is resolved, so we have some concerns as to whether do we need this string. So strings provide a clear advantage for cryptographers. But if we require them for all, of course, it's a major change to existing. So this should be wait and discussed on the list. And if this is discussed, the pair of plus can continue to its progress.
[00:11:59] Ben Seltz: Yes. This is this is the only thing holding up both our draft and Valerie's draft. So, yes, we're both very keen on on people discussing this. Jonathan, I assume you're next in queue.
[00:12:08] Jonathan Hoyland: Yeah. Yep. Jonathan Holland, Fatejis. Just to sort of echo what Sophie said, the if you look at the K MAX spec, it tells you exactly how to wrap an XOF that doesn't take customization string and turn it into an XOF that does. So, like, even if somebody created a weird XOF that doesn't support customization strings, there's a standardized way of wrapping it so it does.
[00:12:32] Chairperson: Okay. That's useful. Thank you.
[00:12:35] Tero Kivinen: Alright. Thank you. Then we go to the next presentation. What did this matter for? It should work, but, I mean, the device is somewhere here. It's not oh, okay.
[00:13:06] Valery Smyslov: Sorry, took it back to
[00:13:07] Tero Kivinen: Oh, you took that off.
[00:13:09] Valery Smyslov: Remove the slides. That's fine. Alright.
[00:13:11] Presenter: Okay. Thank you, everyone. So I'm here to share our latest experience on the PQC using regarding to the RFC nine three seven o and to discuss about some improvements and maybe improvements on the ADDK algorithm. So I'm going to skip the agenda. So first, I I let me give some recaps to the background. So, obviously, we are testing the PQC migration, our products. So I'm I'm from Huawei, and we're testing about how to use the RFC nine three seven o by using the hybrid key exchange. So the RFC basically has seven transformer type a d d k one to seven, which is a type six to 12 to the I k e I c unit to combining the different helmin with one or more post quantum cams into the SKC. So the think the negotiation model here is very simple. So the the initiator will list the candidate's cams and the per addk type, and the responder must select exactly one transformer for each proposal type. But there there are some there are two restrictions in the RFC, I think. The first one is responder choice must not contain the duplicated algorithm. So that means you cannot have the identical transformer ID across different ADDKE. Is that for none? And that is requirements in the section two. And another one restriction is only the ADDKEI I tend indication none can be optional. Otherwise, one algorithm must be selected. So here's the problem. Think first, I think the end of the day, I think as the goal, the migration goal is as long as two entities supports the same PQC algorithm, they can negotiate and to reduce the overlap in the negotiation process. But sometimes, while while we're testing the our products, we found that the developers policies often comes on some Internet templates where they find some internal instructions that can call some you know, the format is right in the SE payloads, but they carry some misused candidates across the ADDKit can. So here's our two scenario we are really facing when we're testing the product. The scenario one is completely complete overlap. Let's see the initiator sends the ADDKE list, the chem chem one and chem two, and the k two, also the chem one, chem two, the copy paste, and the k three, also the chem one, chem two. And let's see the responders supposed both. And to select the algorithm, the chem the k one can be selected in the edit k one and the cam two can be selected in the k two. But no distinct algorithm is left for the k three. So that caused the negotiation fails. And another scenario is a subset overlap, as we quote. Maybe the developers don't know the man or they forget to add it. So let's say the Ke1 includes the cam one, cam two, and the k e two includes the cam two. But the responder supports cam one only, so it can choose the cam one in the EDD k e one, but cannot satisfy the cam two, KE two because it's not optional. It's mandatory. So it can also cause a negotiation field. So here's our proposal. At least it's as an option. Maybe we can extend some selection logic in in the responder. Firstly, we think we should strictly follow the instructions of the current RC. That is one algorithm, one ADKE, Or but if we found maybe it cannot be satisfied, we can use some extensions in the c one and c two is consideration one or two. The consideration one, I think it's we can consider the two have the duplicate algorithm selections. That means the responder may select the same algorithm for different ADDK transformer type. And consideration two is to implicitly the non selections. That is maybe the responder may add a non, that's a transformer ID zero for an ID key type even when the initiator did not listen to make it become optional. And the obvious obviously, and the c two can be considered as a fallback mechanism, and it is require recommended only after the c one fails. So maybe carry some security impacts, and we we have some analysis later. So here is a I think the if we extended the processing flows, that should be it. So first one, we follow the current RFC. And if it's not it cannot be satisfied, then maybe we can use compatibility executions to include the c one or even include the c two. And as as the third one is if we did include the compatibility executions, we need indications, either in band or auto band to tell that that should be you that is the use, and the initiator can choose or choose not to accept the selections and the derive the s q c. So here we also in the draft, we we have a draft and to discuss this about in the annex to show some examples. I'm not going to too much detail. Maybe the case one is using the c one and case two is using the c two and the case three is supposed to using the c two, but the local check, it cannot be fallback, so it's abandoned. So the case four is you can use both the c one and c two, but c one is priority, so we use the c one. So maybe we also have some other options. So this is a draft during the email discussion. We talk about today how to should we extend it to the some logics or should we not? Maybe some the other options, maybe we can we shouldn't maybe this is a pure implementation issues, and some experts think we should not consider about some extensions. But I think it's still valuable. Maybe we can have some guidance for the current ADDK arrangements in the working European in the future to maybe resolve some concerns or issues for from the developer side. So maybe next step, we have I I propose some options. Maybe option one, we can consider this this about the extensions of the normative or information guidance. The option two, maybe no extensions, but we we can consider some guidance for the developers under the current ADK. So I I'm happy to have some questions.
[00:21:20] Chairperson: Valerie, go ahead.
[00:21:22] Valery Smyslov: Valerie Espinosa for this plus. I'm very much opposed to this change because it adds fuzziness to the negotiation process. So currently, the negotiation is deterministic and you say that, well, let's assume that we assume that while proposals this initiator actually means that it is not it doesn't mind that some of these proposal are skipped and known and assumes. So in your examples, both in your examples, implement initiator is really broken. It's really broken because its proposals are is broken. It it proposes proposals that cannot be satisfied. And there are a lot of things in the IQ two, in the original IQ two that can be done the same way. For example, RFC seventy two ninety six requires that all encryption transforms for AEAD must be played separately in separate proposals and encryption transforms. It's just a pure encryption. And initiators just can mix them. So it is broken in this term. And it so fix your implementation. Don't add fuzziness to the negotiation.
[00:22:41] Scott Fluhrer: Okay. Scott Fluor of Cisco Systems. I would agree with just Valerie just said. If if you if the you propose k one MLKem and Frodo and proposal two MLKem and Frodo, you're expecting to have two separate proposals, exchanges defaulting to just one is wrong, and an implicit none is even worse. Thank you.
[00:23:12] Presenter: K.
[00:23:14] Paul Wouters: Paul Valters, Libriswan. Yeah, I agree. We we had this discussion on the list. I'm really glad we did. But but what what came out of it for me was that all the examples raised in the draft are actually not correct and they cannot happen with a properly implemented client. So we also do not implement this.
[00:23:29] Presenter: Okay. So I I think it's I think it's implementation issues, but the consider the extensions here with it's just some roughly thought. But we I think it's valuable to have some instructions later. May maybe under the current RFCs, we we can give some maybe in the future work, we can give some instructions. But currently, I agree the draft is not concentrated on that part. Maybe we can do it later.
[00:24:06] Chairperson: Yeah. I will
[00:24:07] Presenter: continue to discuss in the email list.
[00:24:10] Presenter: Alright. So so I think
[00:24:11] Tero Kivinen: the call I think what we can do with that, we can keep the draft running, we can update it, and we can, you know, maintain it. I don't think we actually probably going to be published as an RFC, but it's it's useful for people to actually work on and think about it. Alright. Next one. And don't steal my clicker now.
[00:24:38] Presenter: Thank you. Okay. So my presentation is for the for the key. Yeah.
[00:24:43] Tero Kivinen: Yeah. Your mic. Okay. Okay.
[00:24:52] Presenter: So it's a photo for IKV2? So my update is quite easy, actually. Yeah. So the first page is for the general information. So we're gonna talk about it here. Yeah. So this is the update for our new version zero one. So, basically, we have some changes here. First one is actually we changed the reference, We also changed the title. You you know, our original title, we have the keywords hybrid because after getting the opinions from The Middle East, yeah, we also added the content such that it's not just used for hybrid exchange using for a low. I can also just run for a low along. There are different ways either by the reliable transport or just because maybe they don't have the MTU MTU issue in that case, we can just run such an item as well. So we changed the title. Now, this actually also suggested by several experts for the is the last meeting. Yeah. Before the last meeting, I mean, actually, because it is that during the group adoption group adoption proceed to. So now we we can say we totally solve this question. That is okay, I think. Yeah. It's good. Second one is that we just know because in the beginning of June, so for example together with several other algorithms, yes, has been actually formally published by ISO. So the content is ISO dropped already. Together, we we probably also know actually that two drafts in CFRG now. Yeah. One for the free to KEM algorithm. Another one is for free to KEM security considerations. So just like you say, I do know there is several new key algorithms, part of them have security considerations. So say, have a g going to do some consideration or extract key algorithms. The result could be available, yeah, in weeks, yeah, according to the chairs of. Yeah. Okay.
[00:27:13] Valery Smyslov: So I mentioned that
[00:27:13] Presenter: they swap already. So I think that's all. I don't have nothing else. So from the viewpoint of the authors, we thought the draft is actually ready for the hour to do last call. That's those suggestions or comments? Yeah. Please.
[00:27:38] Scott Fluhrer: Okay. One thing which hello. Scott Fluor, systems systems. One thing which will be a RC blocker is that there, the only reference definition of what photo chem is is an ISO document under a payroll payroll. I believe that you cannot publish an RC with that as a normative reference. So you'll need to have some oh, do Deborah? Deb, you want to talk suspect? Yeah.
[00:28:10] Presenter: Please, Deb. Yeah. Any comments?
[00:28:28] Deb Cooley: Oh, this is Deb a cool Deb Cooley, sec. It's it's tricky. Right? I mean, you there needs like, you need to be able to see the reference. And if the reference is behind a paywall, it's difficult. Right? I think there are ways around it, but none of them are great. I actually know the answer to this. So I will have to take an action to find out for sure. Unless you know. Do you know? Do you have an idea? So,
[00:29:05] Chris Hopps: yeah, I don't I don't have an exact answer for you. But Chris Hop's lab n. Also, the the it's okay. Also, co chair of LSR. So my experience here is I'm gonna try to bring to bear. Also, previously, co chair of ISIS. And ISIS wow. I'm only an inch away. ISIS is a protocol with a standard behind a paywall. That ISO ten five eighty nine not publicly available because it's an ISO standard. So there are ways to do this. It it can be done. A lot of times, we work with liaison. There's usually, like, some kind of early draft that you can get to for free, but it is not technically a blocker because the ISO is a yeah. It's behind a paywall. Yeah. Alright. It's not it's not easy.
[00:30:11] Valery Smyslov: Well, there is for this plus speaking as a co author of this draft. Well, Scott, and there is a draft in from Peter Longa and the team, which basically defines a. It's of course, it's not behind the play wall. It's drafted. No. No. I don't think it's part. It's it's make it alive again. With this effort in to all camps, this draft, I think it is currently active.
[00:30:43] Scott Fluhrer: Unless until attacking RFC, I don't think the Scott Fluor again. Until it's actually a actual RFC, it's not considered stable by IETF.
[00:30:56] Valery Smyslov: We can wait.
[00:31:09] Tero Kivinen: It's me. Yeah. Yes. The no matter how we get around this, I will be very much against normative in referring to any paywall crypto. Alright. So that's think it's that one. Then we go to the next presentation. We have still left five. We left for that.
[00:31:29] Presenter: Yeah. Maybe it's that's further.
[00:31:35] Tero Kivinen: No. It's just I have to click the slide quicker. Yeah. That's yes. It should be now.
[00:31:46] Presenter: Okay. Yeah. Thank you. Okay. So this this is another draft. Got the multi authentication. It has been it has been presented into the last meeting in.
[00:31:58] Paul Wouters: Yeah.
[00:31:59] Presenter: So this is the second of the presentation. Closer to the mic.
[00:32:02] Tero Kivinen: Oh, okay.
[00:32:03] Presenter: Sorry. Hold it in your hand then. Yeah. Maybe. Yeah. Good idea. Thank you. Because it broke my Little
[00:32:12] Tero Kivinen: closer. Okay.
[00:32:13] Presenter: Okay. Thank you. So for this one, yeah, the main change is that we just add a whole section, yeah, as the section four to carefully compare the proposed mechanism and the previous one, because the multiple authentication introduced the, I'd say, 4739. Yeah. It's quite, yeah, quite some time time ago. We also updated as a reference and did some additional changes. Yeah. As we mentioned in our original draft, the base of ideas that we would like to provide quite a flexible authentication called the multiple authentication or multi authentication. Basically means we can combine freely now using different available single authentication message in the registry for I k e v two. This is the idea. Yeah. We think it's could be a a good idea. Yeah. So we we like to check the opinion from all the experts here. Yeah. The original motivation is quite simple because they are real real life. Yeah. If we were like a open bank accounts, normally, you are required to provide some kind of verification, like your identity, where your address, something like this one. For identity, for example, it could be your IC, yeah, or your passport, and for your leaving address, could be some billing address or some payments, yeah, information, etcetera. So we just would like to mimic this one in our draft for authentication the I k e v two. Also, actually, the case to change for I k e v two is also doing this one similarly. Yeah. By the RFC nine three seven zero. I can also adjust to do the traditional one first by considering about the MTU limit and then do the PQSA case change. Yeah. Giving you a number of ways. You'll second one of the set for a pose case changing message. So like the one of them. So we will like to do this for authentication Because currently, the authentication negotiation in IKEv2 is not so rich. Yeah. But there is a r f c nine three nine five. It gave us a framework. So we we follow this framework and it's in ten days such that we can do such a kind of the multi authentication. Yeah. This is the basic idea. Okay. So here is a detailed comparison before before between our current proposal under the previous one. So what we can say is that our purpose and the message are a still still different. So for our purpose, we would like to multi authentication just in in in the available IKV2 authentication message. But according to my understanding, the RFC four seven three nine is more concerned about something kind of okay. A two layers of authentication that can say that something like this one. Okay. To do the IPsec communication, okay, exchange authentication. So maybe there is a two layers of authentication like this one. Maybe advice devices. Right? Yeah. The device maybe needed to get the network access. Yeah. To do authentication with the network operators. After that, maybe the user also needed to do authentication to get to the content behind the VP and Harvey in the central. Yeah. But our way that we have different as we mentioned. Yeah. Another one is that for the message on mechanism in the previous one, the authenticity can do this one one by one. If I do the first authentication once they're finished, I may probably do another. If you agree, you'll be great. If you agree after this one, we may even can continue one more. So gradually, the further authentication is something as well. So here we propose is that we first negotiate what kind of authentication I like to authenticate yourself to me. And of course, you can also propose which kind of a combination authentication message You will require me to authenticate to you. So we're first the negotiation and then do the multiple authentication one by one later. Yeah. This is the main purpose. But, of course, before another discussion a few days ago, So some some experts also suggest whether we can do it just that I'm able to do PQSA authentication in preference one. We were also consider this one. Okay. I think this is my idea. I don't know exactly exactly the examples. It's answerable where we suggest the presentation already. Yeah. Just repeat or complete. Yeah. So also no time. I just finished here. Yeah. Scott, please.
[00:37:33] Scott Fluhrer: Scott Fuller Systems Systems. This is a this is a protocol which says how to negotiate how to do multiple authentications, but doesn't say how that actually happens. If you say you can propose to saying, I want to do RSA based authentication and NLDSA based authentication. Okay. What happens in the protocol to actually do that? Do you actually send out to us certificate signatures. You don't specify.
[00:38:03] Tirumaleswar Reddy: Mhmm.
[00:38:03] Scott Fluhrer: That Yeah. That sort of thing needs to be filled out. Thank you.
[00:38:06] Presenter: Okay. Yeah. So currently, it's a deal mainly focused on negotiation.
[00:38:11] Tero Kivinen: Yeah. You are good.
[00:38:12] Presenter: I agree, actually. Maybe later when you can say that about how to finish authentication. Maybe one by one, maybe some case can combine together, but this could be more complex. We will consider later. Yeah. Thanks. Yeah. Valerie, please.
[00:38:27] Valery Smyslov: Well, there is miss love with plus. And note that announcement authentication method doesn't guarantee negotiation. So actually, the responder that sends this announcement has no idea what's initiator, what what's the identity of initiator try to establish this say. So it only announced that it supports some kind of authentication method, but, well, it's not negotiation currently. So in your draft, you just makes it negotiable. It's a big change. It's a change to the way I was announced works now, how it works now.
[00:39:10] Presenter: Okay. Thank you. I will consider later. Yeah. Will discuss with you. Thanks. Yeah. Sefisme-
[00:39:17] Sophie Schmidt: how do you make authentication negotiable without there being downgraded tax? Like usually the problem is if you try to negotiate what to use for authentication, the attacker can just choose what the weakest one is and set for authentication.
[00:39:36] Presenter: Sorry, I did not get a question. What does it mean, downside?
[00:39:39] Sophie Schmidt: How do we prevent that if I, as a client, say RSA and MLDSA is fine and then the attacker changes that to only RSA is fine, how do we prevent this doesn't get into forgeries? Like, the server could only could only support RSA and the client would not know that that is the case.
[00:40:07] Presenter: Okay. I guess probably we actually just send a number of sets authentication. I would like you to do it. I do not know whether you can support. Yeah. If you cannot support either of them, it could be a problem. Maybe just the authentication failure. Yeah. Yeah. Later, I check I check I check you for more detail of your comments. Yeah.
[00:40:28] Valery Smyslov: Thank you.
[00:40:30] Tero Kivinen: Alright. So I think, that's it for that. Then we see move to the hybrid PKL authentication stuff. We have two presentations of that.
[00:40:41] Presenter: Oh, yeah. I will do that next one. Maybe Jean can now do it.
[00:40:45] Tero Kivinen: Oh, okay. So you're gonna do the next one. Okay. So that's it. So just to just be able to go forward? Just Yeah.
[00:40:58] Presenter: Oh, I see. Okay. Yeah. Oh, okay. So next one, I do the presentation on behalf of June as a co author. Doctor June who actually stay in California, so this time he cannot come. Also, this this present time is not very good. It's a very late night in USA, so he cannot come. I do it in a private way. Yeah. So this about the post or contact on traditional hybrid k authentication, the ITV tool, but then mainly can say the two gen two signature authentication. Yeah. Actually, the proposed the two ways. One way is just to use the composite signature with the composites PKI certificate. Yeah. Defined by lab work labs working group. Yeah. The other way is the studio use the composite signature, but the certificate can be used that relate to the certificate in the published as a offset already. So here, we propose the two types of the composite, the signature authentication, type one and the type two. A related draft is by and Scott. So to relate a little bit later, we will introduce. So we believe the content is basically for the first one using composite signature together with the composite certificate to do authentication. It's quite overlapped. So we're also considering how how I can sleep the draft or imagine draft to some way. So we also would like to check the idea from The Middle East and all the aspect insights. Okay. Motivation approach, actually, I mentioned already. Yeah. Let's go for this draft. I also mentioned, we propose to composite the signature authentication, but the certificate can be in two ways, either by a composite certificate or by a related certificate. So best of all the by RFC nine six seven three. Yeah. So here is the change, especially we change the authentication announcements defined by I've say nice nine five nine three. Yeah. Such that we do not change the payload formats. Yeah. So we add some detail about the certificate of request and also ask how to verify the certificate. Yeah. This is the main change. Here is more detail about how we do composite the signature or composite authentication by two types of the certificate. Left side, I will leave
[00:43:51] Tirumaleswar Reddy: it
[00:43:51] Presenter: to and follow this one. Yeah. The right side is about the two certificate. But they just use the relationship certificate RFC. So maybe I do not go to go to the detail. Yeah. So here, gave the format, announcement format together with the three examples. The first three example about the composite signature with composite certificate. The the third one, yeah, is composite signature authentication. Is it related to certificate? Here's the authentication code flow. So it's quite normal. Yeah. So just within IKV2 framework. So here, it gave us the a little bit of detail, different steps to do the certificate request because we have the two scenarios. So left side and right side. Similar for the to the about the how how to generate the signatures. It's a composite signature here. Yeah. And then how to do verification is a bachelor of our certificate as well. Yeah. About the security considerations here, I would like to increase is that is is just that that's actually here we require the signing keys must be not reused because here, have several situations. Maybe just to use the pure PQ signature for for example, for m l d s a. You may run authentication just to use MLDSA or may use it to use the composite certificates or may use it for related certificate. If if you wanted in the three cases, we mean you should be just a different case now for m l m l d s a even it's a same algorithm. Yeah. This this is what it does. Yeah. So this is a very cautious way. Yeah. Okay. That's all. Yeah. I would like to get some suggestions and comments. Yeah. Thank you.
[00:46:11] Tero Kivinen: Yeah. I think we take the comments after the second presentation, think, because I think that's we had the second presentation about the same thing, and I was thinking about having comments after that. Or is that okay?
[00:46:23] Tirumaleswar Reddy: Yeah. I had a comment on the dual certificate, but not on the composite one. Right? So if you see look into your draft, right, the the dual certificate is using the composite words. Mhmm. Right? Composite words mandate that it has to be a composite key. It has to be generated together. But what you're doing is you're taking two certs independently generated probably by two different CAs and then using a composite void. That's not what the draft allows. Thank
[00:46:52] Presenter: you. Okay. Yeah. Thank you.
[00:46:57] Tero Kivinen: Alright. So because we as I said, we have a second presentation about the same topic. So let's have that one first, and then then we have a then we probably want to discuss about the relations between those two things charts. Mhmm. Right?
[00:47:11] Presenter: Okay. Thank you. Thank you all.
[00:47:24] Tirumaleswar Reddy: Good morning everyone. I'm Tiru. I'll be talking about hybrid post quantum and traditional authentication for IQv2. This is this draft is just about using composite signatures, which is which is already in the RFC detail queue. It does not talk about dual certificates. Right. We have a presentation also in the TLS working group coming on Friday, which is gonna talk about composites and dual certificates. So there's a lot of relationship between what's happening here and the work happening in TLS. So composite signatures, as a quick recap, combines both PQC and traditional signatures and public keys and treated like a single public key and a signal signature for any any protocol which is trying to use it. It defines one algorithm identifier, which defines the composite scheme, include the including the full parameter set of each constituent algorithm. There are several discussions happening on why you would need PQT hybrid authentication. One of the main reasons is basically that especially MLDSA being a lattice based scheme, there are risks and bugs or vulnerabilities in MLDSA which triggered the work in lamps to have this composite work. And and and during the transition phase, during the uncertainty, there are several deployments which want to use traditional and p q c's algorithms together during the p q c transition. So this draft is quite simple. I mean, it does not do any on wire changes or protocol changes like we do. It reuses the digital signature authentication method. The composite signature is carried within the auth payload. It reuses the standard auth payload format. Composite algorithms are advertised via supported auth methods. It requires no new payloads, exchanges, notifications, new formats. As as a prerequisite to using composite MLDSA, it has to be preceded by m ML-KEM key exchange as it would require to ensure that a CRC could not break that and and reveal the SA key material and and the key exchanges are after the key exchange, the the certificate exchange and signature validation is similar to any other certificate based like we do deployment. The rules the this draft also talks about the rules associated to composite certificate processing. The end entity certificate must contain a composite public key. The composite signature algorithm in the auth payload must match the end entity certificate's public key algorithm. Any mismatch would fail the, I guess, a negotiation. And and the complete signing and verification is is for the composite scheme. It's totally opaque to iQV2. It will all be done by the composite ML DSA crypto library. And and one major advantage of this is it's one searching and one odd payload, which provides the hybrid assurance. Yeah. Hybrid authentication can be paired with both PQT hybrid or post quantum key exchange. Otherwise, sequence cryptography relevant quantum computer could break and recover the SA key material. Since the PQT signatures and certificate chains could exceed MTU, fragmentation becomes mandatory. The composite signatures supports incremental update, especially for brownfield deployments where you can incrementally deploy and deposit composite signatures. You can start with peers which offer both traditional composite or both so that you can, interrupt, evaluate the performance, evaluate any, any interoperability issues, and, incrementally migrate your deployments. And if hybrid authentication is required by policy, you could reject any offer which does not include composite certificate or signature to fail the IKC negotiation. So the the properties of of composite signatures also are discussed in the document with this basically is composite gives you UFCMA. So forging the signature requires breaking both the components. Right? What SEO CMA adds is it only prevents a different valid signature on an already signed signature. But the signature that's generated in iQV2 is unique for iQV2 session because of the fresh nonsense and SPAs. So impersonation requires a valid signature on the new IQ two, which which composite prevents. So in a nutshell, peer identity cannot be spoofed even if one of the two algorithm breaks. So this document complements the IPQC auth. It uses the same work, same framework, PQC only there, and PQT hybrid here. We welcome more comments and suggestions on this and consider for working group production.
[00:52:41] Tero Kivinen: Alright. So I think we have two drafts now about the center. So what question is there is that is there really need for having two drafts, and can we actually combine them, and what's the difference is that should be done for them?
[00:52:59] Tirumaleswar Reddy: I'm I'm open to combining them, but the other document talks about dual certificates, which needs a lot more discretion, basically. Right? So I think I think on the composite signatures, both authors can get together and make progress. But on the dual certificates, we need to stick together and design and come back to the working group. So that way, I still prefer two drafts, one draft where we can work together and progress the composite signatures because it's quite mature, and and the composite signatures is already in. The dual certificates is something that we will have a discussion
[00:53:29] Tero Kivinen: The question there is for the working group really is, do we actually need the you know, anything else than composite is something that is both in both draft and both the both are people think that that's ready. Do we actually need the other other way of doing the exact same thing?
[00:53:43] Chairperson: K.
[00:53:47] Tero Kivinen: Most of same thing. Alright. Scott.
[00:53:49] Scott Fluhrer: Okay. Scott Fluor Systems Systems. In my opinion, if if they want to cons if the work group wants to consider both ideas, they should be in different drafts because they are fundamentally different. Putting trying to put them into one basically means essentially stapling the two ideas together, and I don't see how that simplifies things. Thank you.
[00:54:10] Tirumaleswar Reddy: Yeah. I agree with Scott.
[00:54:15] Paul Wouters: Paul Wouters. I've been also sort of standing back a bit and waiting a bit more on what's happening in lamps and the uptake there about various schemes and different authentications and mixing and hybrids, and so I'm hoping to wait for another three, four months to see what I might need to implement. But I would also prefer to have one solution, not two.
[00:54:47] Presenter: Yeah. So, personally, I'm prefer maybe we can say the yeah. Composite the authentication first. Yeah. I do agree like a type two, yeah, from gene structs. It will be more complete. Yeah. So it may simply do that one. Yeah.
[00:55:04] Tirumaleswar Reddy: Thanks, Julian.
[00:55:10] Deb Cooley: So this is Doug Cooley without a hat. I don't know what you're expecting LAMPS is gonna do more. They already have pure draft specified. They already have composite drafts specified. I mean, they're not all the way through, but they're they're done, both signatures and key exchange. I don't think there's a plan to do more in LAMP, not that I know of. And there's like 18 options for signature.
[00:55:39] Tero Kivinen: So we need one more?
[00:55:41] Valery Smyslov: This is
[00:55:43] Deb Cooley: No. And then you want to bring into the mix like one certificate two certificates, and now you've basically doubled it, right? I don't know. I don't know. I am only your AD, right? And I am not wearing a hat at the moment. So you do what you want. This is the working group's business. But my comment is 18, really. Alright.
[00:56:13] Presenter: Alethia, carry your red hat. Basically, point is that let's reuse code. We have hybrids in x five four nine already. Let's just put single certificate, single signature on, like, IT level and and use that. I think it will be much simpler for testing and deployment and everything else. Thanks.
[00:56:40] Tero Kivinen: Alright. So I hope we will get get something to discuss on the list, and and we will probably hopefully get, you know, one draft go forward and the other one, you know. I mean, having both drafts, having composite is actually not good. So
[00:56:55] Tirumaleswar Reddy: just come up and Yeah.
[00:56:56] Tero Kivinen: And then come back to the working. Alright. So I think this is the next one is you again about the composite key exchange and reliable transport. Okay. Go ahead. It should be just calling for what next slides there. So yeah. Yeah.
[00:57:18] Tirumaleswar Reddy: I'll be talking about the PQT hybrid composite key exchange and reliable transport for IQv2. The PQC transport problem is because of the UDP transport that's default and used by IQv2 which is the traditional key exchange algorithms typically had MTUs which did not result in fragmentation, but the last post quantum piece basically and the ciphertext would result in fragmentation which which would incur in equity to exchange for for to complete the p q t hybrid key exchange. And with IQv2 fragmentation, the loss of single fragment causes the entire set of fragments to be retransmitted. And the other problem, this is this is this all this we got when we were doing the performance benchmarking internally, and we found out that the standard sequence of approaches, which is traditional followed by PQC key exchange, includes multiple round trips, and each of these round trips adds additional delay, which increases the handshake latency. So we already have this with regard to separating the control plane from the data plane, which is basically running IQv2 or TCP whereas ESP would run over EDP. So piggybacking on that, what we did is basically we realized we could do composite key exchanges very similar to what TLS has done, which is basically combining classical DH and PQC payloads together and completing the entire negotiation within the SA unit itself. And that would not involve any secondary round trips required. And and one advantage that we got out of that was we did not have to define in any of our other documents internally that, hey, we need we need to define what kind of pairings are required. The pairings could be defined in the protocol itself. For instance, the three pairings that are picked here is very similar to what TLS has done to enforce better combinations.
[00:59:14] Paul Wouters: Sorry, a question. You say you can do classic Diffie Hellman and PQC payloads in one single round trip? Yeah. Do you have like an MTU of 7,000? Because I don't I don't know how you do that on an MTU
[00:59:27] Tirumaleswar Reddy: of 1,500. This gonna be running over TCP. TCP.
[00:59:32] Tero Kivinen: Oh, okay. Reliable transport.
[00:59:37] Tirumaleswar Reddy: So with that, right? Yeah. So then we had the challenge of how do we combine these secrets that are coming from traditional and hybrid. We picked the CFRG combiner, which basically not just takes the shared secrets, but also the ciphertext and the public keys and derives the the the eventual k combined, which is fed to the SKC, and the rest of the RFC seven two nine six key x key schedule is unchanged after that. We did some initial performance benchmarking. We plan to publish a paper on that on our test bed and all the analysis that we had done and the changes that we did to Strong Swan to support this. And as you can see, right, especially in lossy networks, right, even with one percent loss, as you can see, we compared UDP with TCP hybrid versus TCP composite, and TCP composite showed best across all loss rates. And we tried with various combinations of traditional plus PQ cipher suites along with MLDS 65. And in all of that, we could consistently see a good performance that we could get from the TCP composite. And very similar numbers with code two five five one nine and and with ML-KEM one zero two four as well. Right? In a nutshell, basically, the round trips got reduced by two. IKE intermediate is removed. Lost density is the lowest, and the latency is also lowest among the three. What we are looking now is we will be sharing the paper very soon, right, And we request the working group to consider this, give us more comments and suggestions, and if it could be considered for working group adoption.
[01:01:40] Paul Wouters: Paul, how to say it. Can you go back one slide? So where you say RTTs, do you really mean, like, RTTs from the network point of view of a packet, like TCP sending, like, multiple packets and getting an ACK back, or do you actually mean from an IKE level, it sends one message and gets one message back?
[01:01:57] Chairperson: Because those are different.
[01:01:58] Hannes Tschofenig: Right? Yeah.
[01:01:59] Presenter: The first one.
[01:02:00] Paul Wouters: The first one. Okay. And my second comment is that TCP isn't very commonly implemented yet on many devices, so depending on it might be
[01:02:11] Chairperson: a bit
[01:02:11] Paul Wouters: risky. Also, networks tend to be very sometimes very hostile to VPNs, And so there, also, you've got to have the risk that TCP will just, like, get blocked easily. But I'm assuming that you're thinking more of a use case of data centers where you don't have malicious
[01:02:28] Valery Smyslov: Yeah.
[01:02:28] Tirumaleswar Reddy: So at least in the use cases where we are planning to use it in data centers, right, at least we didn't have that. So that's the reason we wanted to get these performance numbers out first, right, to make sure that we don't we don't mess up the typical de facto UDP, which is used for IQ two and then cause any problems later down the line. Right? So that's the reason we will publish the paper. Right? But I want the working group to have a look at that and then and then make a call, basically.
[01:02:54] Paul Wouters: But in the data centers, can you not just use a large MTU and stick to UDP?
[01:02:58] Tirumaleswar Reddy: There are some cases where even the MLKM, especially right, with defi hell man. Right? It it goes beyond a particular limit, basically. Right? I mean, the MLKM one with one zero two four. Right? Let's see the sizes. Yeah. It's it's close to 1,800. The public key itself goes to 1,800.
[01:03:27] Presenter: Anthony, can you go up a couple of slides back where you show 1% packet loss on the UDP? This one? Yeah. Why isn't there an entry with 0% packet loss on the UDP?
[01:03:39] Presenter: Oh, well,
[01:03:41] Tero Kivinen: I
[01:03:42] Tirumaleswar Reddy: think there should have been something, but let me check. Before I'm saying percent packet loss, I didn't think we got any any difference in in the three variants.
[01:03:53] Presenter: What so then, basically, UDP needs a lot more setup time even in 0% packet loss. Sorry? So that means the UDP needs lot more setup time compared to TCP when there is no loss.
[01:04:05] Tirumaleswar Reddy: Yeah. The the the net and net, we didn't see any much difference, so we didn't put it in the graph. But in the report, you will see that.
[01:04:11] Presenter: So So at that point, only differential matters, right, with 1% packet loss and 0%.
[01:04:15] Valery Smyslov: Sure. So
[01:04:16] Presenter: that draft that is misleading slide in
[01:04:19] Presenter: there.
[01:04:20] Tero Kivinen: Actually, this is the documenting on that. Actually, one of the things you compare UDP, that's actually it's very misleading because it depends heavily on the implementation of the IPsec. When you are comparing TCP, it actually depends on this, you know, actually operating system. Because if you are using UDP with, I can implement this, I see we send every packet three times back to back. It doesn't matter if you have a 10% packet loss. It still gets so fast, but it basically builds resources. And if you have a UDP implementation IP implementation who retransmission timeout is one second, it's very slow if you have to retransmit anything. So it's not really, you know, saying that you are testing UDP. You are testing specific implementation of the IKE stack.
[01:05:08] Tirumaleswar Reddy: We we just use strong swan basically for all the testing. Yeah. So not no. Nothing nothing nothing which is proprietary implement.
[01:05:18] Tero Kivinen: Alright. I think that was the all comments on that. Okay. So next one is the chem based authentication for a question two with post call to security. And okay. It's Valerie having two presentations. Oh, this is good.
[01:05:50] Valery Smyslov: So this is not my presentation. It was prepared by Yuri Prementary and it discusses a paper who Yuri wrote. I just sent a link to this paper to the chat. So it's just you asked me to make a presentation to to present and to present these slides because of the time zone difference. So full disclaimer, all credits for this paper must be applied to Yuri, and I am in fault for any mistakes or any errors or any because I'm only just the presenter here. So this draft for about using a chem based authentication in IQ two was presented. It's in March in Shenzhen, I believe. And so after that, well, draft is written by Gulen and myself. And after that, Yuri just make some analysis comparing this as approach of chem based authentication compared to the traditional signature based application like we do. And so this presentation just well, make some conclusion based on this paper, just present this paper. So in Equitu, the the hardest part of the migration to post quantum crypt is not a chemist, not it is authentication. It's authentication, not a secrecy because for well, from performance point of view, post quantum signatures are much slower and has much bigger public keys and signatures compared to chems, post quantum chems. Well, at least this is the case for ML-KEM compared to MLDSA. But generally speaking, well, it may be also the case for for for other signature plus quantum signature schemes schemes. For this reason, it is attractive to use only gems and do an implicit authentication. And such proposals are known for quite a long time starting from MQV, HMQV papers and design. We have had and I could one we have had nonce error sign encryption for nonces. And so this draft just follows this way and introduce its implicit can based authentication into IP two. So the pipe analyzes three approaches. So the existing approach, classical approach using signature, implicit authentication with ML-KEM and implicit authentication with McEliece. It compares just the performance. So it focuses on the bytes of the wire, the diamonds, the code footprint, and the security for the skins. And so for the chem based authentication in IQ two, we have to add an additional IQ intermediate exchange. This is unavoidable. So comparing to signature based authentication with hybrid key exchange. We have three exchanges. One, I could say, need one I could submit it and why I cause. So we have two I could submit it exchanges. First, I could submit it exchange perform the forms key exchange. And the purpose of the second I can submit it exchange is to exchange ciphertext which allows us to implicitly authenticate or encrypted with long term public keys certified Public keys is certified in certificates that allows us to implicitly authenticate the ICASA. So it's a penalty. But, well, comparing to the comparing the CPU usage for required CPU usage for signature based post quantum authentication authentication post quantum signatures and chem based authentication, we can see that since ML-KEM is much faster significantly faster than MLGSA, then for the first proposal first proposal when ML-KEM is used for authentication, we can see the 63% drop of the timing of the needed cycles needed timing for to perform this cryptographic operations. For for McEliece, it is still slower than using than signature authentication, but not that much. It is a little bit slower than we perform on MLDSA. And if and they say oh, no. This is also a case. It's significantly slower comparing to MLD assay for signing for for the signing part. And comparing bytes of the wire, well, we can see that using first proposals of MLKM is also significantly decreases the bytes of wire. And with McEliece, it is even more even more efficient if we have preloaded McEliece certificates. Of course, it must be preloaded because the public size is normal. But the sufferer the sufferer text is tiny. So it save us a lot of bytes of the wire if have preloaded certificates from McEliece. And so for the quarter size, we can see that well, first of all, if can base authentication is used, we don't need to have implementation for the signing. We still have to implement signature verification to verify the certificates that contain chem public keys, but we don't. We we we may completely avoid implementing signing. And so for these reasons, footprint of the court can be smaller if can base authentication is used. And also the memory as a RAM requirement can be also smaller, but it highly depends especially for McEliece use case. So it is campus authentication in I p two is negotiable. So you can always come back to signature authentication if p a doesn't support it. So it's it's highly highly recommended to use downgrade prevention to to to protect against possible downgrade attacks because it's the time of can place that authentication is negotiated happens in IKE_AUTH. So downgrade provision is highly recommended. Perhaps it must. So it is hybrid but construction. So it is combines traditional exchange with hybrid exchange and post quantum with post quantum key and post quantum authentication. And so it is a superset of what we use today in IQ two with with additional intermediate exchange. So in security, this implicit authentication is based on reduction to IND-CCA2. Security of the our scheme and well in inherits MQVHMQV guarantees for KCI resistance, forward security, and UK's resistance, and visual authentication. So there are a couple of trade offs. It's additional intermediate exchange needed for identity protection against active attacker. And there is no non repudiation. You can see that there's advantage or disadvantage depending on your model. So in this paper, since that design proposal a is the best one, You can just check it in the paper. And the next steps, perhaps it is was to consider adoption of the chem based certification like we do. Thank you. Any questions?
[01:14:49] Hannes Tschofenig: Hey, Valerie. This is Hannes.
[01:14:52] Valery Smyslov: I when it
[01:14:54] Hannes Tschofenig: comes to performance optimizations, one question to start with is, like, is there a problem today in the first place? You you get performance improvements. Yeah. But there's a cost. You essentially redesign the whole protocol. And what I get out of your presentation is, is probably not a good choice. And so for the for MLDSA and ML-KEM, it's not that bad. Like, there's a little bit of a difference in if you switch to design, but it's I think the like, terms like keys are huge and and all of this is I think this is a little bit overstating it. It's it's not that traumatic. The the other aspect to consider is with implementation is there are lots of ways to shuffle things forwards and backwards. So there are many different dimensions. So there's RAM, heap and stack. There's code size. There's the the power consumption. There's also the over the air overhead. And you can move things sort of on a on a sliding scale. So depending on which implementation you're using, you can have a better performance, like like less CPU usage. But then the code size may be large or you use more RAM. So depending on what you what your what your target environment is, you can pick and choose things. So I'm not sure I would be super enthusiastic to, like, throw everything away and then and then basically start from scratch. Because if you want to do that, then maybe there are other options too. Like, you could like, we could dream wild on what we could do with IPsec if we want to start from scratch again. I I that's all I want to say.
[01:16:57] Valery Smyslov: Thank you. Sure. There are trade offs of using chem based authentication compared to signature. So it's
[01:17:05] Scott Fluhrer: Scott Fuller Systems, a much for for ML-KEM authentication, much of the advantage goes away if you do not have preconfigured ML-KEM public keys. I believe that is a scalability nightmare for for anything that that has talks to a whole bunch of different peers. We ...ikev1 had it for us as RSA pre encrypted nonsense. We abandon that for a very good reason. Thank you.
[01:17:35] Valery Smyslov: Thank you.
[01:17:40] Tero Kivinen: No other comments, so you can go to your next presentation. Just go forward.
[01:17:47] Valery Smyslov: So this might be a joint presentation. Congrats if okay. So this is a new draft that tries to integrate MLS into g I q two for to to to to get some additional security properties. And so if you well, securing multicast is a long topic in this group. It was started from, I don't know, a long ago. And recently, RFC four gsIQUE two ninety eight 38 was published. It specifies how group management should be done using IQ two. And in its architectures, there are group members and group control server. And GCKS has just generates all group keys including data protection key. So it knows all the key even if it's not a member of the group. It just has all the keys and knows what's happened inside the group even if it doesn't receive even if, for example, it doesn't receive multicast traffic. It still can decrypt it or encrypted, send the message and then. And GMs just play passive role. They receive this key, a group key, and use it to encrypt and decrypt traffic and no more. And so recently, MLS has been specified. So Conrad will have some introduction.
[01:19:18] Chairperson: Right. Just a quick introduction to what MLS is. MLS comes from the MLS working group. It's been specified, I think, in 2023 in RFC nine four two zero, and then there's also an architecture document nine seven five zero. And this comes from the kind of the secure messaging space. So it's a protocol that's mostly for secure messaging between, like, user operated clients. But at its core, it's also just a group key agreement protocol. So you can agree on a key with a group of clients that changes dynamically. And the nice thing about it is that it's also quite efficient. So even if you have quite large groups, the payload size and the overhead for key updates is relatively small. It's also based on the chem and signature abstractions, so you can just plug in hybrid or pure p q cipher suites if you want. Finally, what's quite nice about it is that it's not just a group that's a bunch of, like, one to one connections. It's actually it has, like, the notion of a group as a first class citizen. So everyone that is in a group actually agrees on the group state, and part of the group state is who is in the group. And then the application can also add additional state like policy that's shared by all group members, and then you have the nice property that group members agree on a shared key if and only if they also agree on that other state. Coming from the secure messaging space, the threat model is maybe a bit different than what has existed before for the multicast IPsec multicast situation. So in our in the messaging case, like, the server should not learn the the keys, the traffic keys, and we also get some nice security properties like forward secrecy and then also post compromised security. This is just a, like, small illustration. I think you all know what forward secrecy is. And then post compromised security is a nice property that allows a client that has the state compromised to heal by doing, like, a key update. So essentially by key update, I mean the client injects fresh randomness that the adversary doesn't know. Finally, MLS has a proposal commit paradigm, and what that means is that members of the group or even outside entities can propose changes to the group. So for example, removal of a group member or addition of another group member to the group, and then you can have a bunch of proposals, And eventually, one of the group members, the actual group members, does a commit which includes all of these proposals, and that commits that commit enacts all these proposed actions on the group state. And so this allows us to have a flow like you can see here, where the delivery service, which is a third party that's not part of the group, proposes removing Bob from a group that consists of Alice and Bob, for example, and then Alice and Bob receive that proposal. Alice is a group member, so she can do the actual commit that contains the removed proposal, sends it to the delivery service, and then Bob receives the commit and learns, oh, I've been removed. And with these proposals, you can do all sorts of interesting things. And there are some efforts to bring MLS into other working groups. So, for example, we've been looking at QUIC and TLS, and there's a bot later on today that's looking at more stuff that you can do with MLS.
[01:22:58] Valery Smyslov: And so how can we use MLS in j p two? So we just assume that GCKS will act as MLS AS and DS services. So authentication services and distribution services and also it will let as external sender to be able to propose some changes to the group. So MLS objects are transferred inside existing payload for j q two and you notify messages in j q two. So IPsec key are generated using MLS explicitly and to to to get to the the key itself, MLS export to sales. And MLS profiles should be supported, so we should support external senders and no joining groups through external commit is not supported. And well, MLS proposals commit are sent at MLS public messages. So changes to to gIKEv2. So all existing payloads are preserved. We introduced new two new exchanges, GSA MLS request to request a designated committed from the group to generate MLS commit and GSA MLS upload so that a group member can propose some changes to the group or send some MLS subject to this case. No new payloads to new notifications. We optionally reuse a GSA key multicast messages to distribute MLS object to the group, so to to improve performance. So there are two operations on the group, group creation, registration of a GM, removing of GM, and GM initiated cap date. So group creation is very simple. It's just the very first group member just creates a group since proposal for the group to to GCKS. It's established gIKEv2 IKE_SA_INIT message with the GCKS and GCKS I'll send the case to the group, sends a proposal group template, and then this group member becomes group founder. And the most complex thing is registration of a new group member because it requires a commit from some of the existing group members such as a designated committer. Just a case somehow chooses one of the group member to be a designated committee and ask for a commit message from this group member. And then distribute this commit to existing group members and also sends back MLS welcome message to the candidate group member. So game removing also requires a commit from one of the existing group member, but it's a bit simple simple as an I don't know if a new group member. And gem initiated key update is a situation when the group members proposes to update group keys by sending this proposal to and again discuss then distributes the commit to all group members. So what has changed in architecture with MLS? The main change is doesn't generate group with the SEC. So it it is still generate keys for multicast RTSA if it is used. So actually, we have two groups. One is groups for multicast RTK and the other is MOLAS groups. They must be synchronized by GCKS. But it doesn't have access to data protection keys. And GMs plays an active role in key in key generation as a code in accordance to MLS. So, actually, they as a whole or group member generates data protection keys. So thanks. Any comments? The draft is very new, so please send your comments to the list. Hi,
[01:27:04] Daniel Migault: Daniel and Miguel. I just have a question regarding on how the key is generated. I have the impression that with the GIFv2, it's very centralized. So it's a central point that says your this group member is admitted or and this is this key. I'd like to understand if MLS has a different perspective where when a member joined the groups, all the other members can say, I mean, whether the member is admitted or not, or is it a little bit more decentralized management of the group? Is that the difference between the two mostly?
[01:27:45] Chairperson: That's a very good question. So MLS is is not really concerned with policy enforcement. It's just about the key agreement, essentially. So what you can do is you can you can have the like, you should make sure that all the clients and the server agree on the policy that the group wants to enforce, and then the server can centralize can centrally enforce that policy. And because the server can see who gets added and who gets removed, and then can say, no. No. You're not allowed or please remove that member.
[01:28:22] Sean Turner: Hello, Sean Turner. I'll try to keep this quick because I see there's a lot of people in the queue. I guess I'm here to I'm an MLS enthusiast and I think that one of the interesting things is group IKEv1 and group IKEv2 are not well deployed. I think gIKEv1 got done because the area director threatened to close the working group down if it didn't get done. I read the Shepard write up for g e v two and there's no known implementations. Here is a gift horse where there are people who have a protocol that does exactly what you need, which is group key management. We should try to figure out how to work with that so that you can merge the two. So the there is a complexity argument here, but there's code and it does work. So that's that's what I wanna say. Thanks.
[01:29:07] Tero Kivinen: Yeah. John. Yeah. MLS is state of the art group key management. I think this would provide significantly better security performance, trade offs, and a lot of old protocols. So if people want to use group IPsec, I think, yeah, this is worth doing.
[01:29:28] Jonathan Hoyland: Jonathan Hoyland, Fortetius. This is very exciting to me because this is, like, chapter six of my thesis from six years ago. No. Ten years ago. Anyway, it's very exciting.
[01:29:47] Valery Smyslov: I'm just asking to send your comments to the mailing list to discuss this draft because, well, it's very new, and your comments are very much appreciated. Hi, Carlos
[01:30:02] Carlos Aguilar: Aguilar from Sandbox AQ remotely here. Thank you for the presentation. There has been a few presentations around the PQC issue and the impact of different approaches to the latency and when you introduce PQC. What would be the impact of moving to this group setting using MLS in a PQC setting, would we see a significant improvement with what we had seen what we had with GCKS before, or or it it it wouldn't impact it?
[01:30:44] Chairperson: Sorry. I'm not sure I understood the question. Is it about the the
[01:30:48] Carlos Aguilar: Is it is it more like a with respect to the previous group implementation, is this approach going to bring benefits in the PQC setting because of the commit approach or the one wayness of exchanges in MS or things like that? Can we expect an improvement in the PQC setting too?
[01:31:14] Chairperson: Okay. Sorry. Maybe the audio.
[01:31:17] Valery Smyslov: As far as I know, there is a cipher suite for MLS, but I since that well, there might be a lot some problems with transport problems because of the size of the MLS commit messages with PQC. I'm not expecting MLS, but still, as far as I know, there are some proposals for adding PQC to MLS. And we also have post quantum key exchange hybrid post quantum key exchange in IQ two that can be used for initial, I can say, stable unit cost, I can say, between GM and GCKS. So the p q c aspects, PQC issues can be addressed, but we we haven't sorted them out well yet because I said that it is very new draft. It's just we're trying to combine two very different technologies.
[01:32:18] Tero Kivinen: On. Hannes, last words.
[01:32:21] Hannes Tschofenig: Yeah. Hi, this is Hannes. The recent my understanding of the reason why we don't have a lot of implementations and deployments of the group key management scheme is not because of complexity and so on, but it's just that the use cases are very niche. And that's why there was no interest. Changing the protocol doesn't make the niche use case more popular. So I think we are approaching it from a very wrong angle here. We need to think about what are exactly our use cases and what are the the requirements for these use cases. Not, I think we get it totally backwards here. And also the people who have been come to the mic, I haven't seen them ever in this group. And I think the goal of this group is not to publish someone's thesis. So we we need to think about that very clearly. I think there's a need for group key management, but one that makes the thing simpler, not more complicated. And I think we are we are and and appreciate the work and the time you spent, Valerie, on on the existing work. But what now we are making that more complicated. We need to go the other direction, make it less complicated. I understand that those have different security features, but I believe that's what it what will make it easier for deployments to enrich the the number of use cases or have larger number of use cases. So that's my
[01:33:55] Chairperson: take on this.
[01:33:56] Valery Smyslov: Yes. Actually, I totally agree with you, and I think Conrad agrees with me. So we we we definitely need for use cases because currently, it's just some technologies that well, it's fancy. It's interesting. But, of course, we need new use cases. And if we we come with real use cases, then it will be much more ground for pushing this technologies, this combined technology further. But I agree with you. Alright.
[01:34:29] Tero Kivinen: So I think that we've all finished with that, and we don't have time to open it. We're already four minutes out over the time. So but anyway, so let's bring that to the list and people can discuss there. Alright. Thank you for joining us.