**Session Date/Time:** 21 Jul 2026 14:30

[00:00:04] **Chair**: The current BOF, they continue updating and budgeting for rekeying encrypted network transport off. This is the ITF Note Well. It is a reminder of the processes and policies, including about conduct privacy and intellectual property rights, you agree to follow when you participate in the ITF. Please read it carefully. You are encouraged to read the source documents to which the Note Well refers. If you have questions, please talk to the working group chairs or area director. Your area director is over there. Meeting tips, especially for the people remote, please try and use a headset if possible. The sound quality tends to be very variable and depending on the rooms of where we are. For instance, I, as a as a chair, now hear lots of echoing while the previous chair who was sitting here didn't hear anything. So things change, so be careful. Use a good microphone and headset when possible. Do not use your video when you're not speaking. Apparently, not use personal hotspots, but I don't think that's a problem at this ITF. This is our agenda. It is very tight. Hopefully, the speakers will give us a few minutes back so that we get some more time to discuss. The important part of the BOF is that we actually discuss things and not so much listen to presentations. So hopefully, the presentations will be quick at the points of cost and then we can spend the majority of time discussing. Any agenda bash?

[00:01:49] **Chair**: One important point based on previous BOFs. During presentations, we'll only take really short clarifying questions. Clarifying questions cannot start with why. So, if you possibly can, please wait until discussion and there, we will have proper time for a proper conversation.

[00:02:16] **Chair**: So for for those who are a little bit new to this, how does a BOF work? So we're trying to do the initial presentations with only clarifying questions. We're trying to discuss the idea of, like, where can we land this within the IETF. So will there be since this is a working group form in BOF, we'll be talking about the charter discussion too if we get to that point. And then in the end, we will do a poll on the five buff questions or six buff questions that we have, and we will show them later. The focus of the discussion is about the BOF questions. So please try to avoid designing the solution in this room on the spot. That's not what we're here for. We're trying to start a working group and not make the solution. So these are the questions that we will focus on. I'll I'll just give you a second to read them. I won't read them out loud. And I'll do I will be putting them on the screen later when we get to the discussion as well. And then, we'll start with the presentations. So the first presentation, Russ. I have no idea if the clicker works.

[00:03:36] **Chair**: I must have gone

[00:03:37] **Chair**: through you.

[00:03:37] **John Mattsson**: Okay. Okay.

[00:03:38] **Russ Housley**: Hi. So, basically, the last IETF we had a SEC DISPATCH discussion about the ideas here and we talked about the operational technology and the use cases a little bit and it was

[00:03:56] **John Mattsson**: a short discussion. Today, as a network security protocols are optimized for the web environment and we're trying to deal with non browser environments and support for post quantum and using tools that have gone

[00:04:12] **Russ Housley**: through formal analysis. So we came up with these requirements at that list. The key management must provide support at layers two and three and four, do a synchronous key updates, support post quantum algorithms, support forward secrecy, support post compromised security, and have formal analysis. And it would be good if they also did asynchronous communication and supported peer to peer as well as groups. TLS turn the MLS meets all of these key management requirements. We talked about drafts that worked in the TLS space and QUIC and IPSec. The the latter two, this have we've had discussion on the list or we'll have presentations at the IPsec session here. Here, we discussed in the MLS working group, a two party profile of using MLS that is having an adoption call right now. The using MLS as a option or extension in the TLS handshake did not obtain consensus so that work has been abandoned. And Conrad gonna talk about his MLS-TLS draft, but it has significant support and is really the basis of the the BOF we're having today. So the idea there is that you will do MLS instead of TLS handshake and then use the MLS key exporter to derive session secrets, use those in the TLS record protocol for the peer to peer case. The the idea is that it, like, the what's called the slim MLS approach provides the efficient post quantum communication. And for two parties, you can get away with the without some of the signatures in the MLS handshake, makes which it even smaller and more efficient. That approach has running code. There's a pointer to the GitHub repository there. It's being used today in at least one production environment. So there's some confidence that it works and it works very well when you need long running uninterrupted service with seamless resumption when there is a network level failure.

[00:06:58] **John Mattsson**: Next.

[00:06:59] **Russ Housley**: I did that pretty quick.

[00:07:00] **Chair**: Thank you very much.

[00:07:13] **John Mattsson**: Thank you. So I'm John from Ericsson. These are the use cases I see for this work. And they are, to some degree, focused on telecom because that's what I

[00:07:27] **Eric Rescorla**: know.

[00:07:27] **John Mattsson**: So for the secrecy and post compromise secrecy are not new as I'm very happy that post post compromised secrecy has been discussed more, but that has been a best practice for for decades. Then after passive surveillance discussion ten years ago, IAB present wrote the RFC saying that ITF should mitigate static key exfiltration. And what you want to achieve is that if you have compromise of one key, the attacker should not be able to to compromise future or backwards keys in any direction. And here it is about keys, but the same principle applies to connections in TLS. That's why TLS forbid static keys. And it also apply to state in RNG, which was recently discussed in in TLS. You don't want this situation. And re authentication can help if you have your static signature key in a more protected HSN, then that can improve your post compromised security, also for confidentiality, not just integrity. These properties are very important in five g and six Five g and six g has very much many long term connections. And 3GPP SA3 has sent LSs to IETF that forward secrecy, post compromised secrecy, p and reauthentication are seen as best practices. And now, 3GPP is discussing PQC. There's a little bit different between protocols. IPSec, basically already IPSec libraries let you do ephemeral asymmetric rekeying and re authentication, while in TLS, you have to do it yourself on the application layer. And for three d PP, this is sometimes a problem. You might not it might be very complex and costly to change the application layer. So you want everything to be taken care of by the lower layers. It might also be a design principle that the application layer should not be responsible for rekeying the lower layers. I think MLS is a very natural key management for any new post PQC group communication. So if you design something, some new group communication, I think MLS is probably one of the options you should consider, especially if you're doing something new. Five g 3GPP p systems does not have that much group communication, but one group communication system that we already need to redesign because of PQC is MIKEY-SAKKE, which is used for mission critical communication. So police and ambulance. And then I think MLS could be a very good option. Then a lot of other use cases we'll talk about by unidirectional communication is important for for latency and some part might be offline. I would like to highlight that unidirectional communication is important for privacy. I think revealing your location is very privacy sensitive, and I think it's discussed way too little both inside and outside of the IETF. And if you do radio and security, you know that just sending radio even without any information reveals that there is somebody there. So if you go hiking and you send radio, people can advanced with advanced equipment can see that somebody is there. And if you send radio several times, like acknowledgments on any layer, can be in

[00:11:51] **Eric Rescorla**: the

[00:11:51] **John Mattsson**: application or any other protocol layer, Then somebody sending you messages, even you if you are in a in a crowd in a certain place, they can filter you out from other persons and see that this is you just because of the timing. So not sending is important in any place where you don't want to know somebody that you are dear. It makes it much easier to detect. So here's a Greenpeace drone flying over some somebody tearing cutting down rainforest. Whether you like Greenpeace or not, but probably such a drone that does not want to announce it is there. And in some part of the world, just trying to cross a border might get you shocked, then you might not also not want to transmit radio.

[00:12:59] **Eric Rescorla**: Can I ask a clarifying question, or you're not or are you waiting for the very end?

[00:13:06] **Chair**: Please please be brief.

[00:13:08] **Eric Rescorla**: Yes. Can you say a tiny bit more about this unidirectionality, constraint? And what I mean particularly is does the system, do the systems you're working with, say you have key updates. Right? And, obviously, if you had no no unidirectionality, you don't you don't know that the that the packets got delivered. So how much survivability do you need in case of packet loss of keying updates?

[00:13:30] **John Mattsson**: I had very problem. There.

[00:13:39] **Ted Hardie**: So

[00:13:39] **Chair**: in case of unidirectionally, you don't know that the packets were delivered, how much of availability do you have in loss of keying updates?

[00:13:51] **John Mattsson**: Yes. Of course, it's limited if you can only have unit direction. And some security properties you only get when you do a key update in the other direction. But MLS is basically the best you can do in the unidirectional communication.

[00:14:10] **Eric Rescorla**: Okay. No. No. I I I agree with that. The question I was getting at was you sent an MLS key update. Right? And now you and now you have with a confirm with a confirm say, and and so you've got you that ratchet at the key state. And now future transmission just can't be decrypted. And so I'm trying to figure out what the requirement for survivability in that case is.

[00:14:32] **Chair**: Yeah. I I think this is already going into

[00:14:34] **Eric Rescorla**: Okay.

[00:14:35] **Daniel Kahn Gillmor**: Discussion

[00:14:35] **Chair**: territory. Let's let's do that after the remaining presentations.

[00:14:51] **Scott Simon**: My name is Scott Simon. I'm here because Daniel Apon is not, so I apologize for not being Daniel Apon. He had a conflict. So I'll be talking about DroneSwarm

[00:15:05] **Chair**: application.

[00:15:08] **Scott Simon**: I'll try and be brief. I know that we're short on time. In fact, the previous discussion already had a picture of a drone that didn't want to talk about where it was from. So imagine that is part of this too. Right. Good. So imagine you have a trusted drones drone swarm. I guess here there are five drones, but this we're imagining potentially larger numbers of values of five, so you can imagine that as well. So it could be that one of the drones is compromised and key is is collected, and that would be bad. And so let's see. What would you do well, I mean, you can imagine what you would want to do because you're in this room. It's the usual problem of, okay. Well, if we wanted to do just normal public key stuff to try to recover from that, there's an authentication problem because we are not, as the previous person said, we don't want to talk back to the CA that's far away and announce where we are and all of that stuff. So that's oh, by the way, I should have mentioned also there there are some errors in these slides. There it says some things about signatures, and that's not what how you authenticate. You do the usual, you know, Alice encrypts her public key triple ratchet hokey pokey that you're all familiar with. So right. So then I guess one other issue that could happen is if you are trying to recover from that situation that we're talking about with the PCS is you it it could be that the adversary is still listening in, and they might want to also claim to be that drone drone that they've compromised. Well, in that case, that you would see two different parties trying to trying to claim to be the same drone, and you'd realize there's a problem there. Now, mean, you might also say object at this point that, well, what if the the real d one the real drone was destroyed or something, and then the adversary would be able to effectively re the the drone would remain compromised? That is a problem, but it's, in some sense, out

[00:18:07] **Conrad Sandmann**: of scope

[00:18:07] **Scott Simon**: because it's not clear what you can do with cryptography if the drone is and remains compromised. The point of this is that you're supposed to be able to recover after the end of the compromise. Alright. So right. And this is the sort of stuff that we discussed was discussed before about why you want to do both MLS and TLS. Okay. Questions?

[00:18:35] **John Mattsson**: Okay.

[00:18:44] **Chair**: Hannes, you have a clarifying question?

[00:18:49] **Hannes Tschofenig**: Yes, I do. So on the previous slide, there was this, the requirement that you want the DTLS record layer. And it kind of says that, but what's the reason for that? Because the DTLS record layer, as we know, is very old. It has half of the fields are irrelevant by now. It's only maintained for mostly for backwards compatibility with middle boxes. And so clearly, this is a nonissue here if you swap out the key management protocol. So the middle boxes would get a hiccup anyway.

[00:19:27] **Chair**: This this seems deceptively not a clarifying question.

[00:19:30] **Hannes Tschofenig**: No. I want to get the real reason. I want to get the real requirement. You

[00:19:36] **Chair**: you can come into discussion and raise this point. It's valid for the discussion part.

[00:19:42] **Chair**: Hannes Hannes, that's a really good question, but not a clarifying one. Let's move to the next presentation, which is sensors use case. You should have slides control now.

[00:20:02] **Gaëtan Pradel**: Yes. That works. So I'm Gaëtan from SandboxAQ. And at SandboxAQ, we've been investigating using MLS-TLS for a product that's called Active-Guard. So for context, quickly, what is Active-Guard? Active-Guard is our solution for the cryptographic inventory, so to help our customers do the post-quantum transition. And to do so, we deploy sensors in our customer's environment to get data about what keys, certificates, network handshakes, operations, etcetera, everything they use in their systems and we reported back to a central platform to be analyzed, coordinated, and reported on. Because this data is very confidential, we encrypted with TLS. But with that comes a few challenges, and the two of two of those I'm focusing on here are latency and possibly data loss coming from it. Because the sensors are deployed in customers' environments, we don't control the latency of the network or the instability. And latency and instability can do impact user expense. And they compound they can compound to to even lead to data loss in some in some use cases. Because every time there's a disconnection, we've done it at TLS. We have to do a session reconnect, and we have to do a TLS handshake. So it's it's based on c every time. And and all sensors are gathering a lot of data. I think our network sensors has been a benchmark at three to four gigasecond recently over data analysis. So because they're deployed on on low performance nodes often, we cannot accumulate data forever. At some point, we have to drop the load. So to work around that, we could use current existing protocols, like using long TLS sessions, but, of course, that comes at the cost of PCS or user for the session reconnection user resumption with zero round trip and early data. But as the standard states, it's susceptible to repeat attacks and has to be handled at the application layer. So for these reasons, we've been investigating MLS-TLS. So I'm not coming back on what MLS-TLS is, but with MLS, we can do resumption. We we can do a TLS resumption with fresh keys coming from the MLS layer. And because MLS is asynchronous, we can get we can send data at each step of the resumption state machine. So we do get that early data support from the tier zero RTT. And on top of that, we don't compromise on either replay protection because the replay protection is is provided by the MLS epoch transition. We cannot replay an order resumption request with early data because the epoch would have changed and the keys would have been updated. And with MLS-TLS, we also get more post compromise security because at each key updates or resumption, the asymmetric key has been has been used. Yeah. So with MLS-TLS, we could have our cake and eat it. That is to have early data transmission when during session reconnect and but still have a better post compromise security and replay protection or data in the protocol layer and not the application layer. So what are we doing towards it? We're currently doing a security analysis or cryptographers are doing a formal verification of the protocol. We've we're not ready to publish it yet, but we've recently been able been able to generate a a proof for it. And we're doing a couple of implementations, one in Python in parted from the with the the the paper, and another one in the system language, possibly rest that we could use in production. So we've looked in interface and benchmarks, etcetera. Thank you very much.

[00:24:33] **Chair**: Thank you. Akar?

[00:24:37] **Eric Rescorla**: Yeah. I'm sorry to say, but this misunderstands the situation with ZRTT replay, which we can talk about in excruciating detail. But the reason replay is difficult in ZRTT in ZRTT for TLS is about statekeeping between multiple, servers on the same side. And you have exactly the same problems with MLS. It's just getting an inherently inherent problem with statekeeping. It's not a problem about TLS versus MLS. And the reason the way MLS gets past it is it basically abandons the old state and forces you into a synchronous synchronous posture as far as statekeeping. And you can do the same thing with TLS. So, so so, I mean, like, I'm not saying this RTG is not a problem with our work replay, but it's a problem at statekeeping. It's not a problem about, about inherent in TLS. So I'm happy to talk about this more, but I just think this is, like, really quite quite incorrect.

[00:25:21] **Gaëtan Pradel**: My point is that it was handled on the application layout.

[00:25:24] **Eric Rescorla**: No. No. No. You can handle it in the you can handle it in in the t TLS stack in in the case you're talking about as well.

[00:25:29] **Gaëtan Pradel**: Okay.

[00:25:41] **Chair**: Hannes, please be brief. Yes.

[00:25:44] **Hannes Tschofenig**: Have you in one of the earlier slides, you say that PCS for TLS is not available. Did you had a chance to look at the ongoing work on extended key update?

[00:25:56] **Gaëtan Pradel**: No, I haven't looked at that, no.

[00:25:58] **Hannes Tschofenig**: Okay.

[00:26:01] **Chair**: Okay. Thank you. And we are now moving to the final use case presentation, which is VPN use case. Conrad?

[00:26:16] **Hannes Tschofenig**: Okay.

[00:26:21] **Daniel Kahn Gillmor**: There we go. Okay.

[00:26:24] **Conrad Sandmann**: So, yeah, we've built a VPN product based on top of, well, MLS-TLS essentially. And I don't wanna talk about the protocol. I think Russ has already summarized it quite well. So our requirement was focused on this long running connection use case, and we wanted forward secrecy and post compromise security as well as post quantum, the ability to do post quantum. And the one of the requirements was also that the protocol was well analyzed. And some of these things you can get with TLS. And so I just want to talk briefly about why we didn't choose TLS because I think that's going to be relevant probably also for the discussion. And so TLS is at least my impression is that it's very much made for the web, but we're slightly outside of this use case. So we like the flexibility that MLS-TLS gives us with regard to the use of other credentials that are not x five zero nine or raw public keys. In TLS, we even with the extended key update draft and please correct me if I'm wrong there. I may have overlooked something, but I don't think you get explicit authentication of the key updates. So they're not signed by the signature keys of the entity that does the update, for example. I think it's just the cam, and then there's symmetric authentication over that. And the other thing is that MLS as a package already does all of this. And as I understand it, the extended key update draft is still in flux, and it changes things about MLS that would require us to redo the analysis or at least parts of it. And finally, the what we also wanted was a way to do the swap in the MLS working group. We call this use the amortized PQ combiner. So the ability to split between post quantum updates and traditional updates in a similar way that signal does it or, I I guess, Apple did it before them, but essentially have more frequent traditional crypto updates with the more expensive PQ updates, and they're spurs at a lower frequency. And so, essentially, to summarize this, MLS kind of out of the box gave us a lot of the flexibility that we really like for our use case. Yeah. I don't know. Jonathan, I think.

[00:29:21] **Chair**: Jonathan?

[00:29:24] **Jonathan Hoyland**: Jonathan Hoyland for Tejas. Quick question. What does well analyzed mean in this case? Like, MLS has a proof and TLS has a proof, but the binding between them is, well, to the best of my knowledge, not analyzed at all. So my

[00:29:45] **Conrad Sandmann**: from my understanding, and I've looked both at TLS and MLS from the provable security side, is that it's about the composability with the record layer. So TLS 1.3 as opposed to TLS 1.2 has a very nice, like, interfacing between the handshake part and the record layer part, and all you need is a, like, pseudo random key. And if you can prove that's pseudo random, then you can essentially just compose the other half of the protocol. And MLS gives you essentially the same interface where it spits out a pseudo random key, and then you can instantiate the

[00:30:20] **Jonathan Hoyland**: But you but you haven't looked at the binding. So for example, if I say to Alice, use this pseudo random key. It's just an out of band provision key. And I say to Bob, use this pseudo random key. It came from MLS. They would just talk to each other, and they would have disagreement about where the key came from.

[00:30:40] **Daniel Kahn Gillmor**: Yep. Sure.

[00:30:41] **Jonathan Hoyland**: So so I so what when you say well analyzed, what do you mean? Like, have you got a proof that you have a nice binding between the two? Or

[00:30:50] **Conrad Sandmann**: No. I don't have a proof. But there's a difference, and and that's, like, when well analyzed, maybe it should be in in quotation marks. But there's a difference between taking TLS and then, like, changing things, like, for example, doing the extended key update that allows us to get PCS and then analyzing that versus I have much more confidence that I can tie the two protocols together in a good way, then I have the confidence of taking this not formally analyzed extended draft that's still in flux and just, you know, implementing it and using it in product.

[00:31:28] **Chair**: Let's Yeah. Sorry. Capture to the details during the next section. Hans?

[00:31:34] **Hannes Tschofenig**: On the first bullet item, you say only x five zero nine certs and raw public keys. What else do you want to use?

[00:31:44] **Conrad Sandmann**: I mean, well, you other credential formats you can embed other information in? You can have other lookup semantics? Are you saying I could implement whatever I want using x five zero nine?

[00:31:59] **Hannes Tschofenig**: No. I mean I mean, like, you seem to have a certain requirement for the the type of credentials you want to use. TLS provides a number of them. Are you saying you only want x five zero nine then raw public keys? And or you don't

[00:32:15] **Conrad Sandmann**: Oh, sorry.

[00:32:15] **Hannes Tschofenig**: I I don't understand what the first

[00:32:16] **Conrad Sandmann**: point Yeah. Okay. Okay. Gotcha. Sorry. This this is a bit misleading the way it it's there. We wanted more flexibility with regard to credentials and not be forced into using x five zero nine or RPK or, I think, technically, PSKs, I guess, as a way to bind, like, a key to an identity. And MLS has this extensible credential system, and I don't think TLS has it or I have overlooked something somewhere.

[00:32:46] **Eric Rescorla**: It it does. It's just the same thing as a code point.

[00:32:49] **Hannes Tschofenig**: What? Sorry again? Does.

[00:32:50] **Eric Rescorla**: It does. I said it does. It's just the same thing as a code point.

[00:32:53] **Conrad Sandmann**: Yeah. Okay. Then I stand corrected.

[00:32:56] **Hannes Tschofenig**: And for the extended key update, it's an ongoing working group document. So it's in that sense from a maturity point of view. It's obviously way more mature than anything we discuss here, but it also does the signature, the the authentication mechanism. It's just separate independent components that you may or may not use.

[00:33:14] **Chair**: We are running out of time. Again, please, only short clarifying questions. In two minutes, we will start detailed discussion. Carlos? Oh, Jonathan, you're still in the queue, or was it okay.

[00:33:28] **Carlos Aguilar Melchor**: I think it's just that the hand wasn't lowered. So so this is just to to to answer partly the question from Jonathan. So the academic work guide spoke spoke about is precisely about making a full comprehensive proof of the MLS plus ELIS construction. So it's ongoing, but there is academic work being done by our team.

[00:33:54] **Chair**: Not sure if I understood the question. Okay. Thanks everyone for presenting and for clarifying questions. Now, we have half an hour allocated for the discussion before we go into both questions. So, now is the time to ask detailed questions or more generic questions. Both proponents who will be responding to those questions, they don't need to jump in the queue. They can just respond to those questions.

[00:34:41] **Hannes Tschofenig**: Could I have a this is Hannes. Could I have a answer to my earlier question about why the record layer? Like, if we don't need the DTLS record layer, we would just use MLS.

[00:34:57] **Chair**: Right. That's valid question. Does any of the presenters want to speak out on this? This don't fight.

[00:35:14] **Russ Housley**: MLS has bindings to different things outside of the MLS working group.

[00:35:19] **Chair**: Speak closer to the

[00:35:19] **John Mattsson**: mic. Okay.

[00:35:23] **Russ Housley**: So the like the Mimi working group is dealing with binding the the MLS environment to a messaging protocol. The idea is you need something. The TLS record protocols are already there. Why invent something else?

[00:35:46] **Hannes Tschofenig**: Okay. I'll leave it at that.

[00:35:48] **Chair**: Okay. Jonathan?

[00:35:54] **Jonathan Lennox**: Yeah. Jonathan Lennox. I think if this work goes forward, another use case that should at least be looked at is the tip top use case because they're they have needs for cases where you have, like, you know, round trip times in the this is that's this is interplanetary IP. Then we have round trip times, you know, in the tens of minutes for speed of light or days or weeks if things are out of communication, and they wanna be able to do a a handshake. And I think being able to, like, set up an MLS group before you launch the spaceship and then just use that group status for future TLS connections would be extremely useful for them. So I think that's probably something that should be at least that group should be talked to if this work goes forward.

[00:36:40] **Chair**: Thank you. Steven.

[00:36:41] **Stephen Farrell**: Hi, Steven. So I have forgive my forgetting that MLS details. So MLS is a group communication protocol. With the envisaged outcome here, is there or is there not any guarantee that a member of the group knows when somebody else is added to the group? Russ said yes, but and so, yes, there is a guarantee?

[00:37:07] **Chair**: I was asked to be very strict and say that as soon as anybody talks about more than two people, that the use case here is limited to the two party MLS system, and so there cannot be any third parties invited or otherwise.

[00:37:18] **Stephen Farrell**: And is the intent to ensure that things break if a third party is added or are detectable? It might be defined designed for two parties, but every now and then, somebody wants to add another party to an exchange.

[00:37:32] **Chair**: Any of the proponents want to answer that question? Any specialists in two party MLS?

[00:37:43] **Eric Rescorla**: Yeah.

[00:37:45] **Conrad Sandmann**: So MLS, one of the features of MLS is that every party involved agrees on the group state, and the group state includes the, the membership roster. And so it's a feature that you cannot do that. So you cannot have any ghost users or ghost devices in the group except if ex well, except if one of the endpoints right. But if one of the endpoints publishes its key to somewhere else, then what can you do about that? I mean, it depends on how you define end in end to end encryption at this point. Right?

[00:38:18] **Stephen Farrell**: So so so just if it's okay to follow-up. So so, you know, I I'm not saying this should be in in charter or something like that. But if it was in the charter to say that any such addition to a group must be detectable, that wouldn't be a problem technically. Is that fair? Regardless of the authentication scheme you're using? I I wasn't quite clear what the two party thing meant, and it seems the draft seems fairly you know, it has a bunch of kind of TBDs in it. So I'm not saying I'm asking for that to be in the charter, but I think if it was in the charter, that might remove a possible worry.

[00:38:53] **Chair**: Thank you. Steven, you are second time in the queue. Is that a mistake? I guess so.

[00:39:00] **Ted Hardie**: I edited him because I wanted him come back. I really just like hearing him talk. Ted Hardy speaking. Confused because I I came up with a very similar question, and I think I heard an answer. But before I sit down, I want to confirm it. Several of the use cases presented, including MIKEY-SAKKE and the Drone Swarm, can exist in multi party configurations. Right? I mean, MIKEY was a group keying mechanism, as we all recall. And the drone swarms, as presented, can be in a multi party communication. These were presented as driving use cases, but they are now out of scope for the solution because the only thing this group will deliver is the two party case. Do I have that right? And I'm I'm seeing yes, and I'm confused, but I've if it's clear to yes, I'm I'll go sit down again.

[00:39:49] **Chair**: That that also matches our understanding if you ask ask the chairs, but maybe drone use case proponents can

[00:39:58] **John Mattsson**: Yeah.

[00:39:58] **Chair**: Give clarifying response.

[00:40:00] **John Mattsson**: I I think group communication I think it's important to get started. My main use sorry. I think it's important to get started to look at record lay transport layers for MLS. My main use case would be two party. If this start, I think group communication would be could be a natural ex all enhancement in the future. I think it's fine to start with two party.

[00:40:27] **Ted Hardie**: Ted Hardy, as a friendly amendment, you should add that group communications are left for future durations of the charter rather than being silent on it. Otherwise, it is very confusing. Thanks so much.

[00:40:38] **Chair**: That's great feedback. Thank you, Ted. Eric.

[00:40:45] **Eric Rescorla**: Thank you. Yeah. I am also finding myself a little struggling to understand the requirement statement, because I've heard the word MLS a lot, but I actually understand what the problem statement is here a little better. And, you know, we we in the ICF have designed quite a few protocols of this nature. And so I I think we helpful to me would be to see a problem statement for this protocol we for the the properties of the protocol we claim to be designing here and then to gap analysis of why the existing protocols do not meet those standards. And I think I asked for this the last time, I didn't see it, and I still don't really see it. And I think, you know, you see you've heard some pushback now on some of this sort of, ad hoc gap analysis perhaps. And, so I I think that, like, I find that a little unfortunate. I don't think this two party, multiparty thing is quite as, as straightforward as John John Messon seems to be suggesting. I don't think it's obvious. You can just take a, two party thing and cross out two and write many and have the problem and have it be the same thing. So I think, you know, I I think there's a there's a a quite interesting problem here hiding, which is let us design a multiparty group communication protocol that uses a modern key key management system. I think that's an interesting problem potentially to solve, but I do not think we should have to smuggle that problem under designing a two party system and then thinking we'll turn it into a multi party system later.

[00:42:10] **Chair**: Is there a question? Thank you. Suhas?

[00:42:17] **Suhas Nandakumar**: Hi, Suhas. Tim. I was just following up to Jonathan's earlier question about, hey, this been considered for Tip Top and other space use cases? And I just did wanna say that we do have that quick MLS draft that was actually initially proposed to the TIPTOP working group. It went through quite a few bounce arounds through sick dispatch and everything. But that's just to say that we obviously think that there is a particular use case for this kind of, for MLS as a key agreement mechanism for cases where you have intermittent disconnectivity, you have really long latency due to the orbital mechanics, or just the distance between here in Earth and Mars and the moon. So in those cases, the DTN working group at least has a strong support for adopting MLS. It's just not really clear at this point whether that's gonna be done through adding it as a part of BPSec or adding it as part of QUIC because that group is also trying to adopt QUIC as a convergence layer adapter. So tune in for more on Thursday if you wanna join that session. We're gonna highlight some of the implementation details that we found in our work. So yeah, invite you to that session on Thursday if you're interested in seeing another use case for this.

[00:43:51] **Chair**: Thank you. Thank you. Jonathan?

[00:43:56] **Jonathan Hoyland**: Oh, sorry. Jumped in morning for DISPATCH.

[00:44:00] **Martin Thomson**: I would I would like it to be quite

[00:44:02] **Jonathan Hoyland**: explicit whether the multiparty is in the future, like planned future charter of the working group or not because that changes very much what kind of analysis you'd need to do to say whether this was secure or not.

[00:44:20] **Chair**: Well, we don't really speculate about what the next achievements of a potential working group would be after the initial of working group closes. So that's hard to answer for us right now.

[00:44:31] **Jonathan Hoyland**: Well, I think that's definitely never in scope, then you can simplify your analysis. Or you can say it might possibly in scope, which case you have to do the harder one.

[00:44:39] **Chair**: As far as initial charter is concerned, multi party use cases out of scope. If current working group will be created and will be successful and deliver on the promises, then it might want to pre charter. But that's obviously a lot of we've sent a lot of speculations. So, I wouldn't necessarily restrict us because some future might or might not have happened.

[00:45:05] **Martin Thomson**: Thank you.

[00:45:10] **Chair**: Anthony? Yeah.

[00:45:13] **Tirumaleswar Reddy**: I might need some help from the slides. So since Russ is sitting here, can I ask him a question? Like, you said this draft was present in IP set working group this morning. That's about multiparty. That's a group.

[00:45:26] **John Mattsson**: That's not this group.

[00:45:29] **Tirumaleswar Reddy**: So that's a different group. The one the one presented here by the VPN person, the same person here is only two party. Correct.

[00:45:36] **John Mattsson**: Okay. The multiple graphs. K.

[00:45:43] **Chair**: Chris?

[00:45:47] **Christopher Wood**: Chris Wood. Thanks for the presentation. I I suppose there's from plus one Ekr's comment. She said that the problem statement was not exactly clear here. I I I was a little bit late because I was attending another meeting. So I perhaps it was discussed a bit more upfront, but what I heard was more or less like a solution being waved around in search of a problem. Now the, like, long lived session use case that I I I was mentioned just a little while ago is, you know, perhaps closer towards an actual problem statement. Though I'm not it's not really clear to me why something like just, you know, rerunning quick or rerunning TLS or whatever should sessions time out is not feasible or is, like, somehow a deal breaker for those particular use cases. So I'd I'd kinda like to understand a bit more.

[00:46:35] **Conrad Sandmann**: But taking a step back,

[00:46:38] **Christopher Wood**: it's unfortunate that both questions are phrased as such because there's really nothing on here that asks whether or not people would be interested in implementing whatever is put forth here. Now I've heard, you know, suggestions of interest in solving particular use cases, but that does not map directly to people actually implementing things, which I think should be sort of a first class consideration for any new work. So I would also like to hear if there's people interested in actually implementing this opposed to just pulling something off the shelf like TLS or QUIC or whatever.

[00:47:10] **Deb Cooley**: Thanks.

[00:47:11] **Chair**: So if I understood you correctly, you think we should add above question. Are you interested in implementing or deploying the resulting solution?

[00:47:21] **Christopher Wood**: Yeah. I think that's pretty informative.

[00:47:24] **Chair**: Great. Thanks. Hi there. Daniel?

[00:47:31] **Daniel Kahn Gillmor**: Yeah. I Bob, question one, I think, is is it's it's it's still it's still missing for me because I don't my understanding from what I've read is that we're looking at we want I mean, the the name of the mailing list is about forward secrecy and post compromise security. Right? And, if that's the goal, then we have a number of other options available to us. I mean, Chris has mentioned just now of of, you know, rerunning the TLS handshake gives you the post compromised security that you're looking for, and doesn't require putting in MLS. When the MLS work started, my biggest fear was that MLS was gonna be used as a as a stalking horse to sneak in multi party, keying to what was at one point a two party protocol and what we expect to continue to be a two party protocol. And the use cases that are presented here, despite the text about two parties, really does not look like that's been well communicated or well agreed upon even among the proponents of the BOF. So I think we might need to go back. I I I really don't wanna see TLS turn into a thing where you say, oh, well, you wanna do TLS with me? Fine. But here's a third party that is gonna be that's gonna have a escrowed keys to get access to it. And I don't want this to slip the IETF down that down that track. So unless there is a clear explanation of what it is that we're looking to do, just saying, I've got peanut butter, I've got deli, let's put them together and make a sandwich, doesn't seem like a great reason to start a working group.

[00:49:10] **Chair**: Thank you. Hannes?

[00:49:14] **Hannes Tschofenig**: I agree with Chris and Ekr about the use cases and the order of the solution and then the search for the use cases. What I disagree with Chris is the question about implementations because nowadays, unfortunately, with AI, the implementation is essentially are started now and at the end of the path, the implementation is done type of thing. So everyone can do that if they if they have enough tokens available. A sad news for John is that if we indeed add group communication later on, the DTLS record layer is not going to be a good fit because it's a two party protocol. Just saying that upfront, like, not only is it, in my opinion, useless, invent something new if you want to do so or use IPsec, etcetera. But going forward, that would be not tremendously helpful.

[00:50:04] **Chair**: Thank you. Tom? Hello.

[00:50:09] **Scott Simon**: Thanks.

[00:50:12] **Tom Jones**: The strapping MLS onto TLS sessions seems like a good way to strap a whole lot of stateful clients and servers and them agreeing with each other, but the things pitched today don't really seem to make use of that in a way that we couldn't already do by just having, for example, more session tickets that are just one time redeemable, for example, to resolve this zero RTT issue. What I do think that Moore State could, for example, do, it was in one line in the slides in the slides somewhere is amortize the cost of post quantum key exchange. I saw nobody really motivate that use case or people that were interested in doing that sort of thing, but that I think is sort of the most interesting thing here. But the problems pitched today for the most part didn't really motivate that we need this and what problems are solved by MLS that we couldn't do. So I kinda agree on the I don't really see the gaps explained well enough yet.

[00:51:23] **Chair**: Thank you. Usama.

[00:51:25] **Usama Masood**: Usama, to you, Dresden, thanks for the presentations. I would like to raise my support for this. A lot of formal analysis work for both of the protocols, TLS and MLS, have already been done, and I want to raise my support that whatever's formal analysis work would be required for the hopefully formed working group, I would like to contribute in that. Particularly, what I want to say is that the gap needs to be clear. And from a chartering perspective, I would like that the fat process, which is existent in the TLS working group, we really continue that tradition that we do not break any such properties by the composition of the two protocols, TLS and MLS, in isolation being proved, but the composition also being proposed being proved. So the milestones where it says September 2026, adopt, and then '27 February 27, publish it. I would like that we have something

[00:52:26] **Stephen Farrell**: Right.

[00:52:27] **Tirumaleswar Reddy**: So so so let

[00:52:28] **Chair**: let's wait for the milestones and the discussion because if we get to the chart discussion and milestones, we could discuss this, but let's not preempt that right now because the milestones are just like a straw man proposal at this point. And also, to point out that, in general, the IETF does not require any working groups to do kind of formal verification because we do not have guaranteed resources for that. While the working group could have a charter where they sort of, you know, try to promote doing formal verifications, it is very unlikely that there would be a charter that says that it is required. And that's just independent of the topic. Right?

[00:53:03] **Usama Masood**: Right. So so I would just say that it may not be required. It might encourage the researchers to be involved, and I would like to offer my support for this work to be done that I can Okay. From my perspective, if I can

[00:53:15] **John Mattsson**: do the following. Carlos.

[00:53:19] **Carlos Aguilar Melchor**: Hi. Well, thank you all for the interesting presentations. So I I have heard a few things about implementing ourselves, our application layer to do our own record protocol or or the fact that the use cases are covered by things such as TLS or IPSec. I think the the problem that was presented by is is is quite simple. You have sensors that have to go through multiple gateways until there is a SaaS solution. And, basically, you want your sensor to be ready to decide they want a new PQC exchange. Just send a huge PQC share and start sensing sending sensing data immediately without having any to wait for any replay, any key share, or any handshake state change. So you you you you want to just be able to send a huge PQC new key and start sending your data when you wake up. And as you are going to go through multiple intermediaries, etcetera, getting things back is complicated. And so I really don't see anything that has been seen said here that doesn't make, like, using a TLS record layer with an MLS like system a very good idea, especially in the PQC setting. So there has been many questions, but I I really haven't seen, like, anything that would contradict that.

[00:55:00] **Chair**: Alright. Thank you for the feedback. Tiru.

[00:55:05] **Tirumaleswar Reddy**: Tiru, Nokia. I I felt the group communication use cases were far more clearer the two party communication use cases that were presented. Like, for instance, the MIKEY-SAKKE or the groups form of communication seem to be far more clearer, right, on the need that MLS is required. The the the requirements for two party communication and why TLS fall short. Right? And why can't TLS be updated to do that? Right? I mean, extensions are always defined for TLS, and we have extended key update. There are documents talking about re authentication. Right? I mean, TLS is is an active working group. So if you have problems with two party communication, go back to TLS and do that, right, instead of doing something really new. And and the third comment that I had was with regard to I think the working groups like CoAP and all have spent a lot of time in coming up with DTLS and DTLS profiles for IoT devices. If you're planning to do something new for those, you'll have to engage the right set of folks and make sure it's applicable for such working groups as well and and then it's not more discretion, especially for IoT devices.

[00:56:17] **Chair**: Thank you, Tiru. Rick?

[00:56:20] **Rick Taylor**: Yep. Rick Taylor speaking as DTN chair.

[00:56:22] **Chair**: To the mic.

[00:56:23] **Rick Taylor**: Sorry. Rick Taylor speaking as DTN chair, just to clarify some of the DTN use cases. So we do have some interest in MLS, but it's simply because we have a key exchange problem because DTN round trip times can be hours. So we don't run TLS. That does just not never gonna work for us. But the the ratcheting of key material is of extreme interest to us. What this working group would produce if if the BOF is successful would be of interest to us, we've not directly applicable, but we would be interested in seeing somebody working on standardizing and working through this.

[00:57:04] **Chair**: Thank you. Brita?

[00:57:10] **Britta Hale**: Oh, yeah. Thank you for this. So one aspect to many of mic more? Can't hear me? Get really close. Okay. So one aspect here that was brought up earlier is on the post quantum side of all this. A lot of the sensors and sort of use cases scenarios that were proposed and discussed are on those smaller devices and things that are going to have limitations in some way. Now in addition to that, you have the issue of disconnection. If you look at TLS today, it's a connect and forget paradigm. You have to handshake each time. If you have lots of disconnections, you're doing a lot of post quantum handshakes, and that begins to add up if you have a small sensor device. So one nice thing here, which is in the title of the BoF, is the continuous key agreement. There's a lot of history of this already in spreading overhead of post quantum. Many people here are familiar with the signal protocol. It does that very successfully. MLS, obviously, that's been worked out in the MLS working group. There's a history there. I will also note for QUIC as an example of where we have taken existing standards, in that case, an existing handshake from TLS, and used it with a new, essentially, record layer. This is just doing the opposite, where you have an existing record layer and existing handshake from another protocol that are well established and borrowing that in so that we have network solutions, transport layer solutions, that can work for these sorts of devices in more limited settings.

[00:58:48] **Chair**: Thank you. Martin? By the way, we locked the queue. We have seven minutes remaining.

[00:58:59] **Martin Thomson**: Yeah. Martin Thomson. I still I came in a little late, like like Chris did, but I don't see a use case here. I see, again, a solution looking for for a problem. One of the hallmarks of the sort of AI slop avalanche that we're sort of seeing in some of these working groups is that someone notices a blemish on something and demands that the entire building be demolished and rebuilt. And this sort of looks a little bit like that. I know that this is not AI slop. I think this is, in some levels, kind of interesting work. But as a practical matter, I don't see it solving any real problems. And you really don't want to be those people. So, I suggest.

[00:59:52] **Chair**: Thank you. Give me something more. Mark?

[00:59:57] **Marc Blanchet**: Not glad shit. TipTop enthusiast. I just wanna make sure. So TipTop has been said a few times last thirty minutes, TIPTOP working group. But so those requirements were discussed on the mailing list, but there were never be a consensus on it. And the actual mission security, specifications and verified by the others, from me by the others, do not include those. The only one that is being kinda looked at is post quantum. All the others are so, you know, they are useful, interesting features, but they are not, you know, currently, you know, hard requirements for space missions.

[01:00:48] **Dennis Jackson**: Thank you. Dennis. Dennis Jackson, Mozilla. Yeah, I'm also struggling with the problem statement for this work and sort of be closer to the Sorry. I'm also very much studying struggling with the problem statement for this work. And understanding, you know, the actual use case that it's driving towards solving. I think it's so critical before embarking on yet another kind of change to a key exchange protocol at the IETF. Like, we have enough working groups doing many different variants of this already that I think we should think very carefully before starting another.

[01:01:25] **Chair**: Okay. Since it seems that we won't be doing any charter editing later on at this session, we've got a few more minutes. So we just unlocked the queue for two more people. Please try to at least bring up new things and not things that have already been said. Thank you.

[01:01:41] **Eric Rescorla**: Thank you. Yes. I don't know. I'll try to be new, which is I think that a helpful way forward here would be to step back and write essentially just simply a statement of the problem. And try not to use the words MLS, and maybe I need use the words TLS as much as you could. And, and then when we have a statement of that problem, then we can look back and and attempt to assess whether any existing AI technology solve that problem or their new technologies required. My put for the sake of that problem think most interesting problem I heard here was these, the ones that are, excuse me, out of Charter, which is these these group communication use cases, which seemed like a real interesting problem, though, actually, I think we do not have adequate solutions for, and are not just, as Martin suggests, kinda like in full cities on our existing technologies. So, I think that'd be an exciting problem for someone to attack. And I, but in any case, I think we should have one problem statement. Did that be the place to start?

[01:02:37] **Chair**: Thank you. David?

[01:02:39] **David Schinazi**: Hi. David Skenazi, Google. Plus one to the previous comments about the problem statement. I also have a hard time seeing it. This reminds me of when we published QUIC, and we saw a whole lot of drafts about let's do QUIC for x and QUIC for y. And I'm, as you know, a QUIC enthusiast, but that doesn't mean we should put it on everything. MLS is also super cool, but it feels a little bit like that. So what I would recommend to the proponents would be to try something that just has a problem statement and does not include the letters MLS or TLS in it.

[01:03:16] **Chair**: Thank you. And, Ben Kaduk.

[01:03:24] **Ben Kaduk**: I also don't under fully understand the problem statement. Like, is the first off, like, is the charter the problem statement? It doesn't seem like it's explicit, but I am intrigued by the work, and it sounds like one one of the interesting parts is using non x five zero nine cert credentials, but that's not explicit in the charter, but it could be.

[01:03:44] **Chair**: Okay. Thanks. So what we'll do now is we'll do the first question just to get an idea, and then I think I will load up a slightly different puff question as the second one for follow-up. So you can use the show of hands tools in your light client or full client to give your answer to the first half question.

[01:04:39] **Chair**: Let's get let's give few more seconds. Okay. The numbers seem to be stabilized. So, the notes, there are 23 yes, 67 no, and 11 no opinion. Bear with us.

[01:05:36] **Chair**: I tried to sort of capture also what Ekr kind of already said. Do you think that there's a real problem in this space to solve, but you're not sure if MLS is the right starting point?

[01:05:58] **Eric Rescorla**: My problem is with term in in this space. I think, you know, I've heard a lot of things said in this in this meeting, and I'm sure somewhere in there, there's a problem we're solving. But I'm not sure if you asked everybody what what that problem I thought it was with you. Can answer.

[01:06:15] **Hannes Tschofenig**: Yeah. Fine. Do do you see the challenge we're having? At least I'm having. Like, IoT was mentioned. Like, I've been working on IoT fifteen or so years. Like, I don't understand the requirements for IoT to even answer it for that small part, let alone for VPN and for drones and for

[01:06:41] **Chair**: I will just do what any other person would do and go to their manager. Do you have a better phrasing for me that you would like to see for a follow-up question? You you can you can move this into your conclusion action report end of session speech.

[01:07:21] **Deb Cooley**: Alright. I'm short. So let me look at the rest of the questions.

[01:07:25] **Conrad Sandmann**: Speak

[01:07:26] **Deb Cooley**: closer. So yeah. Okay. Fine.

[01:07:28] **John Mattsson**: I

[01:07:30] **Deb Cooley**: don't wanna trip over the mic stand. So you can't do three because we have not discussed the charter. You can't do four because we have not yet discussed the charter and five or six. So two is, do you think the IETF is the right place to do whatever the work is? So I do think I do think you might be able to ask that question. Right? So the the every pardon? What we okay. So the first question is actually the right question. Is the problem statement clear? And the answer from that is clearly not. So I think the BOF proponents need to go back and relook at the problem statements and make it clear. If you want TLS two party, don't present multiparty. Right? If you want TLS with MLS as the handshake and the record layer, which is clearly will always be a two party system, then you need to you need to think about how those two things go together and and make it make sense. Like, if it's not logical, it's not gonna it's not gonna work. Right? And it's possible that you really don't want TLS record layers. Possible, you want something else. I also and I have not come to the mic to talk about this. I don't understand if it's a long term connection and you fire off a ratchet with a chain and the other end doesn't get it. Now what? Like, you can ship as much encrypted data as you want to, but if the other end never got the key, you're out. Right? And if you're talking space, who's going up to rekey it?

[01:09:17] **Chair**: So would it make sense to ask maybe a question of, is there a problem to solve? Or is that is that not

[01:09:30] **Deb Cooley**: not bad. That's that's a good idea. You may. A

[01:09:38] **Ted Hardie**: friendly suggestion. It might be useful at this time to ask who's willing to work on the next problem statement. Because then you can at least see if you've got people in the room who are willing to help you keep working this forward or not.

[01:09:53] **Chair**: Okay.

[01:09:56] **Chair**: Sure. We're doing it right now. For now. For now. I don't say no to you. You're my boss.

[01:10:15] **Chair**: So, we started a new show of hands. Are you willing to work on clarification of the problem statement?

[01:10:49] **Conrad Sandmann**: Clarifying question.

[01:10:50] **Chair**: So numbers seems to be stabilized. So, we have 23 yes, 67 no, and 11 no opinion. So, we do have a mailing list for these discussions. I highly encourage those who answered yes join that mailing list. So I hope we will have more productive conversations there and clarify the use cases that we want to solve and motivation why MLS-TLS is the right shape of solution to solve those use cases. Eric, are you still in the queue? Do you want to share us? Oh, not anymore.

[01:11:33] **Chair**: Okay. So, unless Deb wants to say any grand closing words, we are done? But okay. Congratulations. You can all go and get some coffee except the baristas are closed, I'm really bitter.

[01:11:54] **Chair**: Thanks, everyone.