**Session Date/Time:** 18 Mar 2026 06:00

This is a verbatim transcript of the MLS working group session held during IETF 125.

**Sean Turner:** Hello. Can you hear me? I asked them to give a thumbs up maybe in the room. Thumbs up in the room? Yep. All right. We hear you. Awesome. Thank you, Mallory. Man, that mic is—it's great to hear you all remotely.

**Sean Turner:** Awesome. Cool. All right. Well, hey, welcome to the MLS working group here at IETF 125. We'll move on to the next thing. It's Wednesday. Hopefully, you've seen this before. This is the Note Well. This is the policies and procedures that govern how we operate here at the IETF. Just want to call out the, you know, IPR stuff. If you see something, say something, and some other things about how we should like treat each other nicely. If you have any problems, you can let the chairs know, you can let the ADs know, you can go to the ombuds people, etc.

**Sean Turner:** All right. On next. Meeting tips. There's some remote people, there's some onsite people. We are going to try to use the queue, so make sure that you put yourself in the queue if you'd like to speak at the microphone. And again, this session is being recorded.

**Sean Turner:** Here's our agenda [Chairs' Slides](https://datatracker.ietf.org/meeting/125/materials/slides-125-mls-chairs-slides-01). Here in the Note Well, we're going to use the Eckerbot to take minutes. Nick and I will review them to make sure that nothing really crazy happens, so we technically don't need a scribe. We're going to do a quick status of the working group, and then we're going to run through the active working group IDs, all but one. And then we're going to do some additional drafts, which have been kind of banging around for a while.

**Sean Turner:** All right. So I guess the quick update here for the status is we did a working group last call on extensions, and it essentially passed. There were a couple of things that needed to be updated, and Raphael has gone ahead and done that. He's going to provide a little bit later, but again, just to remind everybody, the plan was that we were going to wait for additional implementations to go. One of the other things that happened was during that time, we decided to yank targeted messages out and put it in its own draft, and we kind of re-adopted it and we're good to go there.

**Sean Turner:** The amortized PQ MLS combiner draft did go through a working group last call. We did get some comments and some revisions that have been made, and hopefully, Marta—I see her, excellent—will be here and she has a presentation, hopefully, that she sent me either in email or via the data tracker that we can then upload. I don't see it, but she can also present it and we'll get it from her later.

**Sean Turner:** What else is going on? We have Richard in the queue.

**Richard Barnes:** Yeah, go ahead. I'm just speaking for the adopted draft that is not on the agenda this week, which is Light MLS. I think that one's ready for working group last call. We've got it implemented in MLS++ for a while. Would love to do any interop testing if anyone else is interested, but I think that the draft is solid. So, whatever the chairs are ready.

**Sean Turner:** That's Partial MLS?

**Richard Barnes:** Yes, sorry, forgot, used the wrong adjective.

**Sean Turner:** Partial MS. And so, can you share with us what's actually shipped and—and then I think we should probably take a poll to see how many people have read it.

**Richard Barnes:** So, I believe the whole scheme is implemented in MLS++, which is the C++ MLS library. Including annotated commits, annotated welcomes, tree slices, things like that. So yeah, I think basically the whole draft is implemented at this point. I don't know if the second stack has even done interop testing. I don't think I've made any sort of test vectors, but if folks are interested, obviously would love to have it.

**Sean Turner:** Let me find that where Partial go. Oh, it expired, man!

**Richard Barnes:** That's how ready it is. No need to update it.

**Sean Turner:** So good. Hot off the presses. I'm going to do a poll. Please do show of hands. Yes, you read it, no you didn't, or no you don't know if you remember. 52 people, that's a lot. Let it go for a little bit. Two people have no opinion? Yeah, well, you know. That's okay. All right. So I'm getting a sense here that a lot of people haven't read that. So that's one of the big things that needs to happen before we put it through a working group last—or before it gets out of the working group. However, often times, a lot of people wait to read it until it's done. And so a working group last call might be the moment to actually go ahead and get people to review it. If we have actually five people that read it, that's actually not a bad number for this working group, which is kind of small. So in any event, Nick and I will put our heads together and we'll talk about—about doing that. We would definitely be motivated more if there was a second implementation to try to see if we work out the bugs.

**Richard Barnes:** Test vectors?

**Sean Turner:** Yeah, test vectors. Be super helpful. All right, cool. So Richard, could you do me a favor and bump the version even if it's just changing the dates?

**Richard Barnes:** Yeah, I'll do it once I'm done making cookies here.

**Sean Turner:** All right. All right. Seriously making cookies, I love it. All right, so that's it. I think now we're going to go over to Raphael. Raphael, are you—do you want me to run the slides, Raphael?

**Raphael Robert:** Oh yeah, that would be nice. [The Messaging Layer Security (MLS) Extensions](https://datatracker.ietf.org/meeting/125/materials/slides-125-mls-extensions-00).

**Sean Turner:** Okay, one second. Let me find Extensions. All right, go ahead.

**Raphael Robert:** Next slide, please. Okay, this should be a short one. A little progress update here. So we are down to only one open issue from four or five we had previously. So through some discussion and PR merging, we are down to that one. And this one is about something that started as a discussion in the MIMI working group, if I recall correctly. And the contention point here is simply that it's not entirely clear what happens when members can actually mandate extensions that are not understood by other say participants of the same messaging system. I don't want to say group members. So the idea here is to have something that can be put into the group context even though not every member understands what it is, so as to not introduce some sort of gatekeeping by one operator in a federated context. And the proposed solution here—it's only been discussed in a GitHub issue mostly, but that would be that we have a full update and not only a partial one, so that members who do not support a specific extension or a specific component as it's called can actually still be put in the group context and not be cryptographically evicted from the group because of that. So I think Rohan was keen to propose something there. So that needs some separate discussion, but other than that, I'm pretty good. Yeah, Rohan, you're in the queue. Do you want to speak to that quickly?

**Rohan Mahy:** Sure. Yeah. So the simple thing that I proposed is that we have a new extension, which is called an opaque dictionary. It only lives in the group context and it can have components in it, but those components can only be completely updated or removed. They can't be—there's no patch semantics for them. So everybody that supports opaque dictionary knows that they can ignore the contents if they don't know what it is, but they still sit there in the group context and they can correctly calculate things and sign things and everything is hunky-dory. So basically we leave the updated dictionary as is. You can make—you can patch—you can use patch semantics for that. The requirements of updated dictionary are that you need to know how to handle every component that's in the group context, but for app opaque, you don't. My only reservation about this is that I've asked for like—it seems intuitive that we will come up with something that needs this, but nobody has said on GitHub or the mailing list—I haven't asked on the mailing list, but nobody has said like "yeah, we have this concrete use case that would—that could use this." But I mean, I think we will find one.

**Raphael Robert:** Yeah, I think I share your intuition at this point. So then Rohan, what I understand is you sort of proposed that you're going to write up a PR for that. That would be great and then we can discuss that on GitHub or on the list and then we'd be done with that. Next slide, please. Okay, so what's next? Some editorial polishing. I think there are a few inconsistencies in the draft still because it's been some patchwork over the years now. It's been out for a while. And then we can issue working group last call again and hopefully be done with it.

**Sean Turner:** Do you think—do you have any insight into the implementations that we've been waiting on?

**Raphael Robert:** Yeah, good point. So I think OpenMLS has quite a bit of it at this point. I'm not sure as to other implementations, so we don't have any specific interop here.

**Sean Turner:** Okay. Rohan, go ahead.

**Rohan Mahy:** Raphael said—I'm sorry, Rohan said that they've got an implementation as well, right? In MLSRS.

**Sean Turner:** In MLSRS. So that's good. All right, cool. So we can issue the second working group last call. Maybe we wait, you know, a month or two before progressing it, but if we can get people the thumbs up on the mailing list, that gives us a good sign that we can move forward and get done with this, get it out the door. All right. Let me end this slide. Don't go anywhere. I'm going to share the next set of slides for you. [Messaging Layer Security (MLS) Targeted Messages](https://datatracker.ietf.org/meeting/125/materials/slides-125-mls-targeted-messages-00).

**Raphael Robert:** Okay. This one's a little bigger. Thank you. So as Sean already said earlier, this is now a separate draft. There were a few, I want to say editorial inconsistencies in the vocabulary there compared to the MLS protocol, so that has been removed. There were no changes in functionality and there's an implementation with test vectors underway. Would be interested in hearing from folks if they want to implement that as well. It should be relatively straightforward. Next slide, please.

**Raphael Robert:** So just as a reminder, the scope is that this is a one-shot mechanism to encrypt an authenticated message from one member of a group to another, mainly using HPKE. And for authentication, we use signatures specifically from the signature key of the sending member. And then we also export key material from the MLS group and inject it into HPKE. So that gives us another layer of authentication, which is more robust in the sense that both the sender and the recipient actually need to be members of the group. So just compromising a signature key or an HPKE private key doesn't get you anywhere. So this is—this was a minimal scope that is sort of self-contained and we can leave it at that, but there are some open questions that I just want to present today and then we can either discuss now a little or later on the list. Next slide, please. One open question is should we allow external senders? External senders have signature keys. That's pretty much all they have from what I recall. So we could immediately use them actually to encrypt something to individual members of a group. I think it's pretty straightforward, but mechanically we would have to differentiate who's actually the sender because right now we only use leaf indexes for that. Next slide, please.

**Raphael Robert:** So the other question is about the APQ MLS draft we have. I think Marta is going to talk about that in a minute. So just for context, this is about making post-quantum confidentiality and authenticity more efficient by combining two MLS groups. And the question is now what does that mean for targeted messages? So there are essentially like two options here, which is we only use the classic group. That one already has some PQ confidentiality because we injected something from the PQ group into the classic group, but the quality we get here is relatively weak because we have a strangely divided threat model where, on one hand, an attacker could be another group member, so neither the sender nor the receiver of targeted messages, and then have access to that key material. So it's not very clean in that sense. And the other option would be to take the two cipher suites from the two groups and then combine them into a combined cipher suite and use that for HPKE to have the hybridization there. So that's a little more involved typically, but it's probably a cleaner way of doing it. And then there's a secret third option, which is the more creative and possibly handwavy stuff, like wrapping the classical targeted message message inside of a post-quantum one from the other group. So this is not particularly thought through at this point. Next slide, please.

**Raphael Robert:** Right, and last question is, do we want a simple ratchet for efficiency? So I'm going to start with a caveat here. It's very tempting to reinvent the double ratchet or some variant thereof, so we need to be careful. And the question here is simply, is there something that is very canonical that we can just add to targeted messages that makes absolute sense, is not very complicated and is a straightforward improvement? And so what we could do potentially is have a one-way hash ratchet like we already do for the secret tree, where technically we get some fresh key material for every new message. So we would have a notion of a generation again, I suppose. The downside is forward secrecy doesn't really kick in until the receiver has updated their leaf node. Simply because the key material for that is still going to be around, so that doesn't really give you forward secrecy. Yeah, so those are the three open questions. I think that's the end of the presentation, so—it is. Go ahead, Rohan.

**Rohan Mahy:** Hey. So from my perspective, I don't—the applications that I'm working with, I don't think we need a ratchet. We could do one-shot. I really do like the—however, a feature that was not mentioned, I do like the idea of being able to have—to be able to send a single message to multiple—multiple targeted users. And so having that wrapping would be—would be a big feature for some—some use cases that I would be interested in implementing. Anyway, but I'm happy to see—to see this document progress.

**Raphael Robert:** Are you talking about a simple wrapper or some protocol changes?

**Rohan Mahy:** I'm talking about a wrapper so that you can—you can ephemeral encrypt the—the actual message, but then you HPKE encrypt that key to—to a list of members instead of a single member.

**Raphael Robert:** I see. Richard?

**Richard Barnes:** I am also wary of adding ratchets here. It seems like any solution here is—you have to compare it against just making a new group. And it seems like if you want things like for security, like just make a new group. So this idea of capping this to one-shot seems like a nice clean distinction between those two cases.

**Raphael Robert:** Yeah, that's a good point.

**Sean Turner:** In the chat room, Pat Hardy asked, Rohan, can you say more about use cases that require a single message going to the list rather than individual messages to users?

**Rohan Mahy:** Yeah, sure. So if you were sending—sending a message, for example, you were in a group and you wanted to send a message to the moderators, you could be in a large group, you could send a message to only the moderators. It would tend to be a like a one-shot type of a message, not if—if you wanted to do a long exchange with the moderators then you would create a new group for that. That's the main use case. There's a conferencing use case for this as well, but...

**Sean Turner:** Okay. All right, well that is it for the presentation, unless anything—or Richard, are you back in the queue or... No. Okay, good. All right, I think that's it. Thank you very much, Raphael.

**Raphael Robert:** Thank you.

**Sean Turner:** All right. Marta is up next. [Amortized PQ MLS Combiner](https://datatracker.ietf.org/meeting/125/materials/slides-125-mls-a-pq-mls-00).

**Marta Mularczyk:** Hey, I thought I did send the slides today.

**Sean Turner:** I don't see the slides.

**Marta Mularczyk:** So I'm going to try to present them.

**Sean Turner:** Yes. So if you—I think you have to ask for permission and then I give it to you. Click on this, and I hit check green check, and then you should be able to share your screen. And could you just do me a favor and send the slides after the session?

**Marta Mularczyk:** Yes, of course. I've sent them in an email. I'm sorry, it was a bit last minute, everything. I'm trying—I'm trying, I'm trying here. It asks for permissions. Yeah. Might be a reboot. Yeah, yeah, permissions. Why don't you go ahead and send me the slides again to mls-chairs@ietf.org and then we'll move on and we'll do Conrad's presentations then we can come back to you in a—in a couple minutes, okay?

**Marta Mularczyk:** Thank you.

**Sean Turner:** Okay. All right, Conrad, you're up and we're going to go to—no, hold on, you're up. Oh, Rohan's back. Rohan's back with hybrid stuff. Sorry, sorry there Conrad. [ML-KEM and Hybrid Cipher Suites for Messaging Layer Security](https://datatracker.ietf.org/meeting/125/materials/slides-125-mls-ml-kem-and-hybrid-cipher-suites-for-mls-00).

**Rohan Mahy:** Okay. Can I stand this way so I can look at that please? Thanks. Or here? Stand over there. All right. Hi. Okay, so yeah, we did the ciphersuites draft. Next slide, please. So only made two changes. The big change is that it seemed we did not get consensus between a group of people who wanted to keep AES 128 and SHA 256 with nominally 128-bit combiners, and others wanted to use stronger AEAD and hash functions, AES 256 and SHA 384. So I put both in there. So there are nine ciphersuites. Still countable on two hands. I guess we call that a win. And yeah, just as a reminder, there was no interest in strong—and a fairly strong support for using SHA 384 as the hash for ML-KEM pure ML-KEM 1024 and ML-DSA 87. There was—I found one typo in the editor's copy after I submitted it. I merged that already. As far as I'm concerned, this is ready for working group last call based on all the feedback that I've received to date.

**Sean Turner:** Going... Going... Does anyone not agree with that statement? I guess is where we're going. So Richard, I suspect you're not going to disagree, but go ahead.

**Richard Barnes:** I enthusiastically agree with that statement. I do not care about any of the controversies that Rohan resolved in the last version. I do care about done.

**Sean Turner:** So Nick and I are going to put our heads together about doing a working group last call, unless there anybody wants to get up and stand and say they don't think it should go that way. If you have any reason to object to this union... Okay, that was pretty easy. So we'll take an action there. All right. I think we are going to go back—go to Conrad because I'm still not seeing the slides from Marta. Let's do this. I will do the slides. [MLS Virtual Clients](https://datatracker.ietf.org/meeting/125/materials/slides-125-mls-virtual-clients-00). Virtual Clients is up.

**Conrad Steckley:** Okay, everyone. Next slide, please. Virtual Clients, as a reminder, was adopted I think last—in the last meeting or in the—like after the last meeting. And what we're trying to do here is essentially allow like multiple real clients, as you see in the like small kind of node group in the bottom, like Alice's phone and Alice's laptop, to jointly operate like a single MLS client that represents Alice in multiple MLS groups, you know, as shown above in these kind of big groups. And for now kind of we've focused on the kind of user with multiple clients perspective, but it's also possible to use this to implement other things like I don't know, you have a single, you know, you have a support team and then you can have multiple people representing the support team within MLS groups. Like you can have any sort of hierarchy here if you want. So the advantage, why are we doing this? The advantage is in this kind of one user multiple clients or multiple devices use case that we hide metadata. So other group members will not know which phone or which client Alice is using when she's sending a message. And also if everyone does this and we assume that everyone has multiple clients or an average of two clients, then that actually gives us better performance. Even if that's not like super intuitive in the first place because, you know, you still have to fan out more things and it's essentially you can think of it as one more layer in the tree, but if you like think about welcome messages and stuff, you get a bit deduplication and if you start reusing randomness from individual commits in the small group across multiple big groups, then it actually, you know, adds up to a little bit of performance increase. Next slide, please.

**Conrad Steckley:** So last time again the draft was adopted. What has happened since then? The idea was kind of to merge two drafts into one and that was the Virtual Clients one and Brendan's Subgroup drafts draft and we've started doing that. We've started pulling stuff from Brendan's Subgroup draft over into the Virtual Clients draft and we've started implementing it to kind of get an idea of how it works and what the draft potentially needs to change. And the original thought was "oh, you can just use, you know, any sort of MLS implementation and just implement Virtual Clients on top of it." Turns out it's a little more complicated depending on how you, you know, implemented MLS, but when doing this with OpenMLS, we figured out that you need to do a bit more work because now a client has to be able to process its own commits and there's some more, you know, extra bookkeeping that you have to do if you want to use the same ratchet in a in the secret tree both for sending and for receiving, those kinds of things. And also you have to inject randomness to create commits in a in a way that you're not expecting to if you just use vanilla MLS. So it's a bit of work on the MLS implementation level and a bit more work than I would have thought, but yeah, lesson learned. And yeah, we're in the process of doing that, learning from it, and we'll bring any sort of learnings into the working group as we—as we guess. Next slide, please.

**Conrad Steckley:** So yeah, what's—what's on the list? So implementation and then things will come up as we implement it, I expect. There's more editorial work to do. The draft isn't super—it's not in a super good state, partially because we've been kind of merging two drafts and it's not very—it's not very in a very good, you know, it's not very clear in structure. What's largely missing or what's at least partially missing is in this in this kind of smaller group that's managing all the clients in the in the higher-level groups, we call it the emulation group, and the client management for that is not straightforward and there were some ideas in Brendan's draft and some ideas in the Virtual Clients draft, Subgroup draft, Virtual Clients draft. And yeah, we need to figure out we consolidate them or if we just have multiple ways of onboarding new clients for example, or yeah, how we go about this and I think this is also another place where we learn more as we implement it and test it. And then there's the security considerations section. Here I'm hopeful that we can work together with academia to get some more insights into the details and the nuances if for cases where you actually use that for like multi-client in a user messaging scenario. And so that certainly needs to be done, but there's kind of yeah, I've talked to some—some people who are interested in doing that and so I hope we can, you know, emulate the same thing that we've done with MLS and TLS before and work jointly with academia to make sure we have good security and don't shoot ourselves in the foot here. And I think that's it for Virtual—Virtual Clients. I don't think there is an next slide, no, it's page 4 of 4.

**Sean Turner:** Yep, that's it. Yeah. Anybody else want to get to the mic to say something? Going once. Going twice. Okay, cool. Let's show—so we just keep on trucking. Yep. Go to Fewer Signatures. [MLS Virtual Clients](https://datatracker.ietf.org/meeting/125/materials/slides-125-mls-fewer-signatures-00). Marta, again, we're still looking for your presentation as soon as we get it we'll go on, so we'll just keep going through the agenda until we get them. Even if we have to come to it at the end, we'll do that.

**Conrad Steckley:** Okay. So this is not yet adopted by the working group. This is something I talked about last meeting I think. And here the idea was last talk we were talking about like single signature key packages. Next slide, please. Where the idea was like for key packages but also for other messages, you have a structure where you have a leaf node that's contained in a larger message and both the leaf node itself is signed because it's a leaf node, but also the larger message is kind of signed that has the leaf node within it. And so the idea here with this proposal is to essentially save one signature and only kind of sign the leaf node. And this is a pattern that is present for key packages but also for commits and update proposals or at least commits with an update path, let's say. Next slide, please. And so this is essentially what's happening in the draft, that's what we're trying to do. We try to kind of separate the kind of structural where we have the leaf node which remains unchanged essentially, it's still signed, and then we have the rest of the outer message. And what we do is kind of we take this outer message with a kind of leaf-node-shaped hole in it and hash it all and then put that hash into the—into a component in the leaf node, so it's also covered by the leaf node signature. That way kind of saving the signature over the outer message. And that's especially useful if you have big signatures, for example when you're using ML-DSA, you save like kilobytes of data on the wire depending on your security level of your ML-DSA. But also of course for regular MLS, you could do it to save signatures. Next slide, please. So yeah, last time we were only talking about key packages in this context. Since then we've updated the draft to also cover commits with update path and update proposals. We've also changed the name because it didn't make any sense to call it Single Signature Key Packages anymore, we've called it Fewer Signatures in MLS. And the two caveats is that it only works if the signature key is unchanged because if the signature keys change, there's actually a purpose to these two signatures where the new signature key in the leaf node is actually signed by the old signature key that gets replaced, so we want that kind of coverage. But if you don't change the signature key then that's not necessary and you can arguably get away with not having that signature. Rohan.

**Rohan Mahy:** Yeah, how do you—how does this if you can do this with commits, sorry, I didn't read that section, I just read the older version, but if you can do that, how do you make sure that the member has the group context? Because if you're not signing the—are you saying you're not signing the commit or you're not signing the—the leaf node?

**Conrad Steckley:** You're signing both.

**Rohan Mahy:** Signing both. Okay. So how is this fewer signatures under commits with update path and update proposals?

**Conrad Steckley:** So, yes. So if you have a commit, so if you have a commit it's in a public message or a private message and that's signed. And so you have the signature over the leaf node and then you essentially hash everything else in the message or at least the TBS that you would ordinarily sign in the public message or private message. You kind of take that and you kind of remove the leaf node from it and you hash all of that and put that hash into the leaf node. So it's technically also covered by the—by the leaf node.

**Rohan Mahy:** Right, so only for external commits. Got it. Wait a second. Repeat what you said. Only for external commits. Not for internal commits. Why not? If you used a member commit, then the whole purpose of the—the framed content TBS structure is that it includes the group context. If you're not—if you have no framed content TBS anymore, then you're not—you're no longer hashing over the—you'd basically you would have to hash over something that contained a hash that you hadn't hashed yet. So you have a Klein bottle problem.

**Conrad Steckley:** So yeah, so this is—this is one of the concerns and it's certainly something where I might have gotten it wrong, but my understanding like looking at the—revisiting the whole, you know, hashing transcript hash confirm transcript hash architecture was that it kind of works out the way it's structured, but I'll look at it again and see if I missed something. So yeah, that was within my other caveat that this clearly is not a safe extension, so it changes MLS in a significant way in that it kind of removes the signature and replaces it with a more—yeah, with a more non-standard kind of construction. And so yeah, I'll—thanks for the—for the remark, I'll take a look and make sure it works or if it doesn't work, I'll remove it. Carlos.

**Carlos (Cesc) Guimaraes:** Do we have other settings in which we are receiving multiple signatures because we may be getting distributed multiple packages, multiple messages, or such situations? I mean, I'm wondering whether this case should be a separate case that has to be treated alone or whether we should consider when you have multiple signatures all around in one transmission and whether we could benefit from something like a Merkle tree in which you can like have other advantages besides scalability but also the capacity to send like any subset of messages with a few hashes and only one signature like to update data and I mean it will cover your case but it could cover many other cases in which we could reduce significantly the amount of signatures. Like I—I bring a device that has been disconnected for some time and maybe I will be happy to like really only get one signature if everything was part of some Merkle tree. I mean I'm very far from having thought about this thoroughly but I think if this is a significant change we should consider the different places in which we could save signatures and try to cover them all with only one change maybe.

**Conrad Steckley:** Yeah, I mean that—that makes sense and that was kind of this kind of figuring out where can we—where can we apply this pattern was kind of part of how we moved, so starting with just the key package and then realizing oh, well, you can also do this maybe for commits and update proposals. And then yeah, if—if there are other use cases where some sort of batch, you know, signature would make sense, we could include that in the draft as well. Just that I haven't—it's not occurred to me to—like I haven't found any other use cases. Yeah. I'm open to—to ideas there of course. Okay, thank you.

**Sean Turner:** All right. I don't think there is—oh, there is another slide. Next slide, please. Oh yeah, of course, yeah. So reviews welcome, of course. Last time this draft kind of met with some interest, so we've extended it and so yeah, I'll—I'll re-review the section on commits after Rohan pointed out that there may be like a circular dependency thing here, but other reviews are welcome obviously as well. And then as soon as we, you know, have something that's reasonably stable and functional, we should also consider like revisiting the security proofs or work with people who—who would be interested in that. Okay. That's it for this draft.

**Sean Turner:** Okay. I'm going to see what's available before we decide what goes next. Sometimes it takes a while for the uploaded slides to happen. So I think we're going to move on to the Two Party Profile. Conrad. Okay. [MLS Two Party Profile](https://datatracker.ietf.org/meeting/125/materials/slides-125-mls-two-party-profile-01).

**Conrad Steckley:** Okay. Two Party Profile. Next slide, please. So why are we looking at this draft or why have we written this draft? So there's been—there've been discussions in other working groups where people were interested in using MLS specifically in a context where there's only two parties. And for example, in TLS and QUIC, so in QUIC there is actually a draft that does this that replaces the QUIC handshake with MLS. And there's also a draft by Russ Housley who tried to in—who integrated it into the TLS handshake. And so why are people doing this? It's because so the TLS handshake is already very good for what it does, but if you have long-running connections and you want post-compromise security, then the TLS handshake doesn't really give you that. What you can do in TLS is kind of terminate the connection and redo the handshake that kind of gives you PCS, but it also you know terminates the connection and you know you have to go through all the—the other round trips for the handshake again. And so yeah, this is why we've written this—this draft and another kind of benefit of using MLS here is that we know that MLS is a secure or we have at least some amount of analysis, security analysis, saying that MLS is actually a secure continuous group key agreement. And so it kind of fits this purpose and it also nicely integrates into TLS and QUIC because the security analysis or the structure of these protocols has a nice boundary between the the key exchange part where the parties involved agree on a key and then the the kind of secure channel part where you just have an encrypted channel over which you transfer data and also kind of in-band within this encrypted channel you can do further key exchange messages that are already part of TLS, at least in QUIC at least too but anyway.

**Conrad Steckley:** So next slide, please. So what are we doing in this draft? It's essentially just on a relatively high level describe how MLS can be used with two parties and kind of focusing on the use case that we have for TLS and QUIC and that's kind of these having these three phases where you have a key establishment phase where initiator and responder agree on a key, and then you have the steady state phase or the secure channel phase where you can do key updates in-band to get post-compromise security and forward secrecy. And finally you have the resumption phase where if you've terminated a connection, you can resume it without having to do the whole key establishment phase over again. For two parties, you can do—you can have a kind of so you don't really need a DS in the way that you might for more parties or at least you can simplify it. And here we've chosen for the very simple kind of ping-pong commit ordering where, you know, one party can do a commit and then the other party can do a commit and each party has to wait for the next commit to the—you know, if I do a commit then if I want to do another commit, I have to wait for the—the other party to do one. For now, the draft only contains vanilla MLS, but it's also conceivable that we can optimize MLS here for the two-party case, although of course that would kind of negate the nice—at least partially the nice security analysis we have already because that would almost certainly, you know, essentially change the protocol in an unsafe way. Next slide, please.

**Conrad Steckley:** So yeah, this is just a sketch of how the Two Party Profile works or what it describes. Essentially the initiator sends a key package, the responder looks at the key package and sees if it's, you know, if it's compatible in terms of capabilities, version, and ciphersuite and that kind of stuff. Then sends back a well—like creates a group locally using the key package, sends back a welcome to the initiator. And now you have a group set up for both parties and then you can do commits in a ping-pong style. If the connection's terminated, you can just do a commit to resume the connection. And you run into some issues with—like you get into the issue like if both parties commit—like try to resume at the same time, who wins, those kinds of things, where you can have a simple kind of tie-breaker where you say "well the person with the lexicographically higher signature key signature public key wins and does the first commit" or you could just say "well the person who was previously the initiator also always wins if there's kind of there's a concurrent resumption attempt." But yeah, it's as simple as that and it's really just a way for kind of to describe a simple way of how people can use MLS in the two-party case to get better PCS properties than other key exchanges. That's all I have. So essentially saying hey, we're working on this, if you're interested feel free to... yeah, Richard.

**Richard Barnes:** So Conrad, about this protocol flow, is there any sort of confirmation in there that the remote side received process and correctly processed the commit before you start using the new keys?

**Conrad Steckley:** So with this—I think there is a... so I'm not entirely sure because we changed to this ping-pong style. We previously had a more complex thing with, you know, you do a commit and then you have to potentially have, you know, commits crossed on the wire and then you need—you need to have a confirmation and stuff. For this one, I don't think you need to wait or to I think you need I think you send a message to signal that you're now starting to use the new keys, but you don't need to confirm that you've processed it correctly. I have to look into the draft, sorry.

**Richard Barnes:** Yeah, I realize there's a variety of ways to do various asynchronous or synchronous styles here, so yeah there's room to fuss with that in the draft. I should say before I say anything further that Cisco does have some IPR related to this. We did a project with Chrispin a little while back and filed some patents based on it. Those I think are disclosed against this draft, I think disclosures are there, it's the normal Cisco IPR, note those who also use our terms, so I don't think that should necessarily be a blocker on this, but there should be some useful stuff there. I think we've also got some documents that we drafted and never published that I can try and dig up and see how helpful they are here.

**Conrad Steckley:** Yeah, that'd be great.

**Raphael Robert:** Yeah, just going back to Richard's first question. At some point at least, I don't know if that's in the draft right now, but at some point at least, it was exactly as you said, Conrad. We would enter a new epoch but we would not use the key material right away and we would instead signal that we're going to use it by I think signaling the epoch number or something fairly trivial, which then implies that the commit has actually been received.

**Conrad Steckley:** Yeah, we actually do do that, I just checked the draft. So there is a kind of epoch update message that...

**Richard Barnes:** So I think in the version we did with Chrispin, there—we did have a confirmation message which was basically like a finished MAC in TLS that has that same function of confirming you've got it, and you're ready—you've got the keys, you're ready to go, and it also while you're at it confirms that you have the same keys.

**Conrad Steckley:** Mm-hmm. Yeah, I'd love to take a look at these drafts or if you want to, you know...

**Richard Barnes:** I'll—I'll see if I can find anything and put them to the list.

**Sean Turner:** All right. Number one, unfortunately don't know how to say that name. Aubrey's in the queue? Yeah, go ahead.

**Yi (Huawei):** Yeah, hi, this is Yi from Huawei and really appreciate your talk. And just from my opinion, the MLS is like the generalization of Signal protocol to multi-user case, but here you are introducing this like kind of mapping back to the two-user profile. So would you consider like considering comparing to Signal or like how—what's your opinion of comparing to Signal for this solution? Yeah.

**Conrad Steckley:** Yeah, good question. Very valid. So essentially we're using very something that's very—it's a bit, you know, a bit heavy-handed I would say, like something that's usable for groups for something that's where a simpler solution would do like Signal. So I would say I mean Signal is at its core it's more of a messaging protocol depending on how you—which kind of Signal you mean, it's probably connection like a combination between the triple-DH handshake or maybe kind of more recently the PQ version of that plus the kind of PQ version of the double ratchet as well. So if you compare this to the two-party profile, then what we have is certainly kind of less—less, you know, tailored I would say to this two-party case, but at the same time it also gives us kind of more room in the future, so if you wanted to you could come up with a use case where you expanded that to actually do like to a point where you do want to branch into groups and then have a group case where you have a third party that also participates. But and also, yeah, I guess in the context of the IETF, Signal has not really been standardized to that degree. So it's yeah.

**Yi (Huawei):** Oh, thank you. I appreciate the idea of branching into like more user case dynamically. And just to confirm, when you mention this less tailored, do you mean the current your like your solution might be more like computationally heavy than Signal or less?

**Conrad Steckley:** Well, yeah, I think so this what I mentioned in the slides is that there's room to improve it and to make it like to optimize it more for the two-party case and places where it's not optimized for that. It's MLS is more optimized in my mind to the, you know, to large groups and make that efficient rather than the two-party case, but yeah there's probably things you can shave off and I think Richard you've done some work on that.

**Richard Barnes:** Yeah, I agree. I think another way to think about the relationship with Signal is that Signal started out as one-to-one and then a bunch of more proof work had to be done to validate that all the various ways you can build group chat out of it were secure. Whereas we just started with the group case and now we're specializing down from that to one-to-one and we already know the one-to-one is secure by virtue of the bigger proof.

**Conrad Steckley:** Yeah. I mean, yeah, the going the other way with, you know, expanding Signal to the group thing, there it's clear that Signal's missing a whole lot of, you know, cryptographic machinery to get the same guarantees as MLS. So yeah, that case at least is—it's more clear. Okay.

**Sean Turner:** Okay, given this, I'm going to poll the room to see who's read this and who is interested in implementing it, starting with the "who's read the draft." Okay, so it seems like this draft has been read by at least 10 people, which is maybe a record for this room. All right. So of those folks, and you know, even if you haven't read it but you've heard the presentation, I'm going to ask whether you're interested in implementing it. I forgot to mention we have implemented this.

**Sean Turner:** Okay, so we have a lot of interest here. I think we'll take—take this to the list. I guess questions for the authors: do you—are you searching for adoption for this draft right now or is this preliminary?

**Conrad Steckley:** I mean, I think in the—the basic ideas are—oh sorry, Richard, you're in the queue. My bad.

**Richard Barnes:** Oh, I was just going to say that we also have like a research-grade implementation of our variant of this idea, so not specifically this draft, but a related thing. Yeah.

**Conrad Steckley:** Yeah, I mean, absolutely. I think the basics are all there in the draft. As I said, like there's directions that we could take this to improve it depending on what people want to do with it, but the basics are there. So if the working group wants to adopt, we'd be happy.

**Sean Turner:** Okay. It's not unanimous, but we'll take it to the list. Seems like there is a lot of interest. So thank you.

**Richard Barnes:** I might propose, since there's a bit of controversy in some of the other groups about where to—whether this approach is useful, I might propose we maybe hold off on adoption until some of that discussion settles down a little bit. There was some discussion in SECDISPATCH about forming a mailing list and look at MLS in various places. So I don't know, I'll leave it up to the chairs to make a decision, but it might be worthwhile to hold briefly on this.

**Sean Turner:** That's a good point. I'll wait to hear back from SAG and if there's massive interest in this, it could actually live outside of MLS. I think that's the suggestion. Yeah, we'll wait a little bit hear what the rest of the IETF has to say because yeah, this has popped up in a number of different working groups. So... just a note as like as far as I've followed the controversy, the controversy was less about how you do the MLS and rather whether they want to like whether it's fit for the purpose in the other protocols. So it's like I don't think what we've done in this draft is controversial but rather how it's then used outside, but that being said, I'm happy to wait as well.

**Richard Barnes:** Yeah, I agree. It's about whether this is worth doing in various other contexts, not how to do it in MLS. That's right.

**Sean Turner:** We'll take that and set it on it for a little bit. Let's do Marta's. All right, Marta, you're up. I'm going to run the slides, just say "next" when you want me to go to the next slide. [Amortized PQ MLS Combiner](https://datatracker.ietf.org/meeting/125/materials/slides-125-mls-a-pq-mls-00).

**Marta Mularczyk:** Thank you. I don't know what happened there. Something was filtering my emails.

**Sean Turner:** Probably the slides. Yeah, they're pretty slides.

**Marta Mularczyk:** Right, so this is pretty much a state update on what happened to the draft since recently. I don't think there is anything controversial anymore. It's pretty much done. There are two outstanding issues. I'm going to push a PR for one of them today, I hope. So yeah, that's the update.

**Marta Mularczyk:** Thank you. `draft-ietf-mls-combiner` is an alternative to a post-quantum ciphersuite that is a bit more flexible than—than that because it allows applications to choose when to do post-quantum commits and when to do just partial commits that only heal the group against classical adversaries. So this is like a short recap of how this works. So we use two group, two MLS groups, one traditional, depicted on top, and one post-quantum at the bottom. So the main one you can think of is the traditional one. This is the group where we send messages, where we can send commits that heal against classical adversaries. And commits in the traditional group are called partial in `draft-ietf-mls-combiner`. Now an application can choose to do a full commit as well every now and then that heals against both classical and post-quantum adversaries. So this commit is actually two commits. First we do a commit in the post-quantum group, that creates fresh epoch with fresh keys, again secure against quantum adversaries, and we inject that new entropy into the traditional group to heal that group as well. This is done using exporters and PSKs, so we export the secret from the post-quantum group and inject it into the classical group. All right, so this is the recap. Now I'm going to go through the recent changes. Next slide, please. Thank you.

**Marta Mularczyk:** So the draft was renamed from Hybrid PQMLS to Amortized. I think hybrid could also be a—mean a hybrid ciphersuite, so amortized is a bit more proper. New data formats have been introduced to bundle messages from the two MLS groups. So we have a an APQ key package that bundles two key packages, same for public message, etc. So that allows full interoperability between implementations. Next slide. A bit deeper change was about the usage of Safe Application Interface. This is defined in the MLS extensions draft, and the Safe API is basically an interface of MLS that can be used by application components like `draft-ietf-mls-combiner`, identified by component IDs. The use in `draft-ietf-mls-combiner` is twofold. At least as far as this talk is concerned. We use the exporter secret, so Safe Exporter Exporter Secret to export PSKs and PSK IDs. Safe means that the exporter secret can be forward secure within the epoch where it was exported. And then we also use the Safe API to store the state of the `draft-ietf-mls-combiner` double group in the group context extension. So this—the state is like the both—both group IDs, both ciphersuites, and both epochs. And this makes sure that the and this is injected into both group contexts, making sure that they're bundled together cryptographically. So `draft-ietf-mls-combiner` is now fully compatible with the Safe API. We had to update a couple things, so for example, component ID is now set to 6. We corrected some function names and `draft-ietf-mls-combiner` now modifies APQ info that's the state using the proposal defined in the extensions draft. So a bit more details. Next slide. Sorry, the wrong thing. There we go. All right. Thank you. PSK ID was not defined before, so now we use we export it from the group context using Safe Exporter, this part. So we export from the PQ group and inject into the traditional group. Next slide.

**Marta Mularczyk:** Yeah, and a bit more complicated, we use APQ MLS to sorry, we use the Safe API update the update proposal to update the state properly now. This is in the upcoming PR. Right, the picture is a bit weird in the PDF but should be good in the slides. So the way state update update the update proposal works is that has an opaque update data inside and the extensions draft find how it's supposed to be used so applied to in a commit. This is yeah, depicted on the right. So a commit can contain a bunch of update update proposals that go into MLS and the Safe API says that says that the application component that's us should interpret these updates and come up with a new value of the component data that's our `draft-ietf-mls-combiner` state. So the new updated `draft-ietf-mls-combiner` draft is find—defined now how this update data is constructed. That's the TLS serialized struct on the left, that's APQ info update. Right, so we can have a full update or update one epoch or the other. Group IDs obviously cannot be updated.

**Marta Mularczyk:** And the last thing, next slide, last thing is clarification of PQ authenticity. That's a great point made by Conrad, I think. We have an observation in the draft that even with the usage of classical signatures, we get some reasonable authenticity against quantum adversaries even because of the usage of AES, so authenticated encryption with secure keys against post-quantum adversaries, but of course there is also the concept of thin packet, so a quantum adversary could still forge a key package and get into the group anyway if they're active. So that's clarified now. So that's pretty much it. I think the—the draft is in a very good shape. We have two—two small things to fix and there we are. Any questions?

**Sean Turner:** Okay, thank you. So just to confirm, with the new PR that's coming in, this will have addressed all the working group last call comments?

**Marta Mularczyk:** There—there will be another one, a small one, but then I think so.

**Sean Turner:** Okay, great. And so we've done two working group last calls for this, I'd like to have have this be final. So does anybody in the group here have anything substantive to block progression of this of this draft, or is there anything that would prevent us from doing another working group last call immediately? If so, please get in the queue. It looks like we're—we're clear. So Sean and I will discuss and likely we'll do a working group last call again to be final. All right. Thank you, Marta. Sorry for all the troubles of getting it loaded. All right, you are up, Rohan, for the rest of the time. [Ratchet Tree Options](https://datatracker.ietf.org/meeting/125/materials/slides-125-mls-ratchet-tree-options-01).

**Rohan Mahy:** Hello. I'll move over here so I can see my slides. All right. Uh, yeah, so the first one on my pile of drafts is Ratchet Tree Options. Next slide, please.

**Sean Turner:** So we'd like to start by saying that we did a working group adoption call for this draft. There were six people that said that—that voted that—that were in favor. We should have made this a working group item already, so we will correct that. Our apologies.

**Rohan Mahy:** No problem. I also didn't follow up, so mea culpa. Okay, so we did a working group or adoption call and Russ kindly pointed out that there were no security considerations. So I fixed that.

**Sean Turner:** Thanks for reading, Russ.

**Rohan Mahy:** Um, there was also—I had a brain fart and I had this tree signature in place, which is completely unnecessary and I removed it. So, this is implemented to this current draft. I have nothing else to say about this if anybody has some feedback about it let me know, but yeah, it's been implemented in MLS RS and works—works right.

**Sean Turner:** Yeah, and I formally, again, if somebody has any objections to accepting this draft, please stand up, come to the mic. I know it might not be a convenient time for everyone, but it was on the list. Okay. Cool. Cool.

**Rohan Mahy:** Okay. All right. So this is a 01 draft that I mentioned last IETF. [Private External Commits and External Proposals](https://datatracker.ietf.org/meeting/125/materials/slides-125-mls-private-external-commits-and-external-proposals-00). So there have been like only really clarifying updates, but the terminal—the terminology around like how you describe the commit to be that you're using in order to generate new key material is I think a lot clearer. Thank you, Mostafa did most of that—most of that text and I just lightly edit—lightly reviewed it. We also clarified the use of the of which epoch secret, added an IANA consideration section and greatly expanded the security considerations. So, for those who are not familiar with this, the idea here—next slide, please.

**Rohan Mahy:** This is while you have in an environment where your where your distribution service uses private handshakes, you have a bunch—you have all these ways of keeping keeping the data very private so the DS doesn't know who is in the the room. Like it basically can know it can know that it got messages and it can forward them on, but it doesn't really know who is in which group and all that. It can see volume of messages that are sent to a particular group, that's basically about it. But when you go to send an external proposal, external proposals I think were initially envisioned to be used in an environment where the DS was much more aware of what was going on in the group and had group context. But there's still good uses for external proposals and external commits in private handshake groups, and so this rectifies a privacy lack in that case by wrapping this—by wrapping these external commits with encryption so the DS is oblivious to the HPKE.

**Rohan Mahy:** The key is—can you repeat the question? Which key? So there are two keys, which are generated in each epoch. One key is used to generate a signature and the other is used to to encrypt. And so the idea here is that if you got—if you got the group info, you would also have this—you would also have these extensions, and you would get that from another member. So this would be either like you would be sharing it with another of your another device of your same user or with somebody that you trusted in a in a tight group. And then with the group info you would have the group context, the group context contains contains these contains at least the public keys with which you can use to encrypt and authenticate the this external proposal—these external proposals or commits.

**Rohan Mahy:** So yeah, so I did this work in conjunction with Mostafa for deployment in just one in exactly one of those environments. So that's ephemeral or XMTP labs. And they have a client that people use and it's using a private handshake environment. Turm is another environment that uses this. So, and it is now implemented as well. It's implemented on OpenMLS. Okay, I think I'm done with that unless anybody has any questions. Oh yeah, actually can you go to the next slide for this?

**Rohan Mahy:** So there—um, something that I will add in the next security consideration section is to talk a little bit about preventing floods of messages to to the group. And so these—there are some methods on this slide which can be used to sort of, you know, rate limit and and prevent sending a bunch of garbage that then has to be has to be validated by by members. I think you can probably also deal with this at a higher level, but you know. But the point is that there are a bunch of things that we can we can say in the security considerations that are "hey if you need this at this level, here are some things you could use, you could also do it at a higher level." Okay, that's it for this one.

**Sean Turner:** So we're going to do a show of hands here. It's been banging around for a little while, he said it's implemented in a couple of places. One place. One place. But I'm going to do a show of hands for, you know, have you read the draft? Um, to kind of get a sense for because he's talked about this a couple of times. Exactly twice. Twice. Two. One for me. Yeah, I'll do it for you. There we go. All right. Okay, we'll try to see if we can get some more interest in getting this going, but more implementations is better. All right, cool. That's good for this one. Let me go ahead and get the next presentation ready to go. I was particularly interested in doing this one because it's like I've been doing a lot of stuff in the in the DS knows everything kind of deployments, so it's nice to be able to also do something on the on the other side. So, [Web Token Credentials (and others)](https://datatracker.ietf.org/meeting/125/materials/slides-125-mls-web-token-credentials-and-others-00). Very funny, also all combined.

**Rohan Mahy:** Okay, next slide. So this one is also implemented, I've also presented this a couple times. Right now we've got Basic Credential which doesn't do diddly, and we have X.509 certificates which are incredibly baroque. I happen to like web tokens, particularly selective disclosure COTs, they're really nice. Really nice spec that does SD-COTs. Who's writing that draft? Hmm, I wonder. Chairs are going to call poll. Oh.

**Rohan Mahy:** So this is sort of this is pretty straightforward. It just says, okay here are two new container types, or sorry, two new credential types, one for one for something that can be an SD-COT or plain COT and one that can be an SD-JWT or a plain JWT. Next slide. And in the case of JWTs, you have this really nasty base64 encoding and at the top level of the base64 encoding, this credential format could actually can actually solve this by un-base64ing it and using it in its structured components and save a lot of space. Right? Because this thing there's like somewhere in here is a is a is a period and somewhere else is a is a tilde and those are separators. Right? So you can go through the thing you can parse it, well why bother, if you're sending it from MLS the client could just stick it directly in the correct format. That's if you want to use JWTs, right. Personally, I'm still partial to COTs because they're smaller.

**Rohan Mahy:** Okay, next slide. There is also at the moment, there is there are some encrypted disclosures in SD-COT. There is an open issue about this. It may be removed, it may stay, but in an MLS context this would allow us to be able to do a to have an SD-COT or JWT that has basic information about the subject which is visible to the members and the DS, and then to have additional claims which could be disclosed to individual—to the members of the room or the members of the group and not disclosed to the DS. I think it's a nice property. Next slide.

**Rohan Mahy:** So that's it for the credentials. I'm not really, you know, I'm not—I'm not asking for anything unless somebody wants to go and implement this because I think the value of this is going to be to have we've got it implemented on our side, but if somebody else wants to interop, I would be delighted to talk to you and I would be delighted to send you some messages and see how that goes. Richard.

**Richard Barnes:** Rohan, should the credentials be `sd-jwt-vc` or `sd-cot-vc` instead of bare `sd-jwt` / `cot`? Or is that a meaningful distinction?

**Rohan Mahy:** I don't think that's a meaningful distinction here. If somebody—somebody has some reason why it isn't, you can let me know, but I think that once you open it, inside the protected header you will find the type and then if you need to act differently based on, you know, a different set of mandatory claims you can do that accordingly inside of your validation logic, but from the MLS perspective you're still carrying the same—the same protected, unprotected payload and signature headers and disclosures in SD-JWT. Sorry, slightly analysis of the others. Only a little bit.

**Rohan Mahy:** Okay. So I've been thinking a lot about what—what problems do we have that—where we have sort of like a bit of a hole in terms of robustness or privacy or basic functionality in Core MLS plus the extensions draft. And so I came up with this list here. So this doesn't include things where we improve performance or we add like the PQ Amortizer, things like that, right. This is—this is just like get basic stuff to work. So in issues that are independent of which handshake style you use, we had, I don't know, Bangkok maybe, we had a presentation or Dublin, I think, a presentation about the malicious member replay within the same epoch problem, right. We should probably get around to fixing this. In my particular application, you know, like if I'm using Mimi, I'm using Franking, I—I actually have a way to prevent this attack at a higher level, but not everybody does. We should—we should fix this.

**Rohan Mahy:** I have a very, very short draft where I talk about external commits ignoring pending proposals, making pending proposals invalid. At this point, I've kind of gotten to the point where I think if you want to do an external commit and you need to go get you need to go get a group info, whoever you got the group info from, you should be able to go get the pending proposals. And I think we should just have an extension that lets us fix that. So I have a draft on that. Brendan presented I think twice on this problem of malicious update paths that can fork a group. This is particularly nasty. I started work on a draft that at least allows a a member to realize that this happened to them and then to prove that it did happen to them. I would love for us to target a solution to this problem because it if you end up, you know, one of the things that we advertised about MLS is that MLS works great in big groups. So if you're in a big group, if I've got a group of a thousand users and I get, you know, three sleepers in the group and they want to mess up my group because they don't like my whatever it is I'm discussing, they can go and mess with you at any time by creating an update path that basically destroys the group and makes it useless.

**Rohan Mahy:** Moving on. So we have a few other things which are dependent on what style of handshake you use. So if you use a private message handshake—I'm going to start in the middle—the external commits and external proposals don't have privacy. That was the draft that I discussed a few minutes ago. So I think we now have a solution for that. We also have an interesting property which is the DS has no way of validating if messages that it receives are signed because it doesn't have the group context. However, we could trivially solve this problem by having a way for the messages to be signed using the hash of the group context and in a commit we could in each commit we could put in the AAD of the commit we could commit to the hash of the group context in the in the new epoch. This would allow a DS to automatically check signatures and throw garbage away without knowing who's in the group. Could be tremendously valuable. So there's a draft for that. Finally for private handshake, we could do some interesting work on forwarding welcomes in a more private way and have a kind of standardized mechanism for doing this. I think it's kind of the lowest item on the list in terms of in terms of priority because people have there already are sort of a variety of approaches you could use. Conrad.

**Conrad Steckley:** Quick question on the—the like the second point in the private message bullet. The signature is encrypted, right, in private messages? So you would have to expose that somehow?

**Rohan Mahy:** Yeah, you'd use the you could use the AAD in a in the message to say this is—this is a signature and, you know, using this particular... And at that point, what are you actually validating at that point? Confused. You know, it's been—it's been at least five weeks since I looked at this, so why don't I—why don't I look at that and get to you after—after the meeting. Okay. Good question.

**Rohan Mahy:** Okay. Um, all right. For public message handshakes, so we had this issue that if you send a public if you send a public message and you've got any kind of federation, other DSs other—other DSs could see your handshakes, not just your hub. Mimi said that they wanted to have a solution to that problem so we wrote Semi-Private Message. Nobody is currently doing federation right now so it's kind of a non-issue, but if it does become an issue we do have something sitting around we could pull off the shelf to solve that problem. We currently don't have a way when somebody sends a group info to verify that the extensions and the signature are correct. We can check that they are compatible, but not that they're correct. That might be nice to fix. And the DS can't check the validity of the confirmation tag. We also might be able to come up with a solution there by having a confirmation signature instead of a confirmation tag.

**Rohan Mahy:** Yeah. So this is just kind of a I've been thinking about this problem about what are we missing and it's, you know, I think it'd be nice for us to be able to say we we've got a set of stuff that does everything we need to have like the same sort of quality of of privacy and robustness properties across the entire protocol. Next slide, please. That's it for me.

**Conrad Steckley:** Quick question. Since like on the if you really wanted to do more checking on the public message side, shouldn't we also, you know, essentially right now we only have a private version of the welcome where the group info's encrypted. Shouldn't we also like also have a like a public version of this where you don't encrypt the group info? Or even like have it outside of the welcome and let people fetch it. That would seem like it kind of would belong on the list to a certain degree.

**Rohan Mahy:** Well, I mean, I think that the way that Mimi works, the commit bundle contains the group info so even if, you know, even if the copy of the group info that's in the welcome is encrypted, the hub still has or the DS still has a copy of what's supposed to be the same group info. Yeah, and like some of these things about how do you tell if if what the clients end up processing is the same as what the DS processes, you know, there's some things that we could do by some clever things we can do in the AAD, we can take the authentication tag and we can, you know, hash it with something and present that and... right. So that worked too. Okay. Thanks.

**Sean Turner:** All right. I guess there's some homework here um for the working group to maybe go through this list at some point more formally and try to figure out what we want to take off. So I mean, I guess the thing that I'd like to ask is are we, you know, is this a list that is worth pursuing in more detail or are some of the one-offs that have already been addressed, is that good enough for now? All right, we can pose those questions on the list.

**Rohan Mahy:** Sounds good.

**Sean Turner:** All right. I'll work with you to make sure I get the—get the questions right. All right. That brings us to the end of our agenda. We ended a little early, but I guess that's probably okay. So everyone gets a little 30 minutes back to your life. Uh, thank you for coming. Thanks for the lively discussion. Thanks for participating in the polls. Have a good day. Sweet. Bye-bye. Nice session today. Goodbye.