**Session Date/Time:** 21 Jul 2026 09:00

[00:00:05] **Sean Turner**: To raise their hands to do that. It doesn't need to be blow by bow minutes. Near merely the highlights and the action items need to be captured. Anybody wanna get famous? I'll buy you a beverage of your choice. Oh, okay. There we go. Okay. Thanks, Eric. Appreciate that. Appreciate that. Alright. It is the top of the hour. Welcome to the MLS session at IETF 120. This session is being recorded. Also, remember, the chat room is also being recorded, so let's try to make sure we keep it professional everywhere. This is the note well. This is all about policies and procedures that deal with everything from code of conduct, IPR, etcetera. The important, there's many important policies, but with the IPR, if you if you know something, say something. If you don't, don't participate. Leaving the room is probably your best bet. Standards process, etcetera, we can explain all that. If you have any questions about anything, you can ask Nick or myself or our area director who is there's Chris in the corner back there. You can ask him. Anything anything. We can go from there. Alright. Next, meeting tips. We are going to use the meeting tool. Make sure that you use the on-site one, the because it allows you to get in the queue because we wanna be able to manage the queue with people that are also remote. Agenda. No. Well, we're doing that now. We'll give a quick status update on a couple of the drafts, then we'll go through the working group IDs first. And then we will go through the nonworking group ideas, which there's quite a lot of, which is good. Lots of interest. Alright. So let's do the the quick status update. We have three drafts that we're not talking about, which are basically ready to go. We had a MLS partial draft that did go through a working group last call twice. We got nothing. Nothing out of the whole working group. So, again, while there's a lot of people here and there's a lot of interest, the list traffic is quite low. The chairs need to be able to point at traffic to say that people read the draft, understood, and think it should go forward. So when we start issuing working group last calls, please take the time to review the documents. We can embarrass you because I know many of your names and try to get volunteers out of you, but I'm hoping that that it's good to just go ahead and review the document. So I know, particularly for partial MLS, that's interesting because I think there's four or five coauthors, and that's many of the people that are active in this working group. So that makes it a little bit more challenging.

[00:02:27] **Raphael Robert**: But I have to talk

[00:02:28] **Sean Turner**: with Rowan, and I know he said he has some comments so we can throw those in and get those revised. But, again, I cannot we cannot progress that those document that document without somebody saying, like, we're good to go. The other document is the MLS combiner. Again, that got revised and is essentially ready to go. It's ready for working group last call. And I guess recently, Rowan updated Ratchet Tree options to the next version. There is a slide deck in there for, like, informational purposes if you wanna see what is what has changed, but we don't think we need to go over that because it's ready for working group last call. So get ready for more working group last calls. Please join the mailing list. Sometimes it's as simply as it's as simple as sending an email that says, read it, and it looks good. Alright. Next, Rowan Minahan, PQ Ciphersuites. This document has also been through working group last call. Did you change the slides? You're doing that.

[00:03:19] **Rowan Minahan**: Awesome. Hello.

[00:03:22] **Sean Turner**: Yeah. Then you have to, like, undo it and then You have to undo it. You have to undo it.

[00:03:27] **Rowan Minahan**: Alright. So how many people have read a version of this the post quantum cipher sheets draft? How many people have read the most recent version? Good. Okay.

[00:03:40] **Mark Baugher**: Hold on.

[00:03:41] **Rowan Minahan**: Let me get So, basically, there is the changes are that we added two more Ciphersuites to the list of Ciphersuites, and that we have a one open issue. The one open issue is related to the specification of the KDF components. The so There you go. Thank you very much. Alright. So we added two new Ciphersuites. Konrad pointed out that if you were going to use the the amortized amortized combiner, not to be confused with a PQ combiner, the amortized combiner draft that you would need to be able to use a a pure a pure ML-KEM Ciphersuites, and you would probably wanna do that with the mandatory to implement rest of the rest of this the pieces of the cipher suite. So that's what this one is for. And we had a concrete request for a post quantum cipher suite that had a that used ChaChaPoly because it's easier to it's more efficient to implement in software. I also fixed a couple of references that were informative that needed to be normative, and we have this open issue. So okay. We have a place in RFC ninety four twenty that says specifically refers to the function extract and the function expand from HPKE and says, hey. We use this to do these things. It's used extensively in in MLS for moving up the update path. It's for used for, the secret tree, but most importantly, it's used for merging and and deriving things in the key schedule. HPKE defines defines these two functions only for two stage KDFs. For one stage KDFs, it does not. And the HPKE post quantum draft, it registers new one stage KDFs, but the only ones that are in the registry right now are two stage KDFs. And then yeah. So, basically, I propose that that we use the HKDF, the HMAC, KDF, SHA three eighty four, and SHA two fifty six KDFs.

[00:06:43] **Nick Sullivan**: SHA two.

[00:06:43] **Rowan Minahan**: SHA two. Yeah. That we use these in in our definition of these ciphersuites. And to clarify, we would still use SHAKE and SHA three inside of ML-KEM. And for those ciphersuites that have a hybrid chem, the combiner still uses SHAKE and SHA three. It uses SHA three specifically as its as its KDF inside of the combiner and that these are just separate things. So this would mean there's no need to formulate a new extract function and verify its security properties. We know that since the hash algorithms in all of these cipher suites are either SHA two three eighty four or SHA two two fifty six, that these algorithms are already obviously available. So this is the most sort of straightforward solution to this problem, and it's also very conservative from a security perspective. We know that it's gonna work. Any comments?

[00:07:58] **Sean Turner**: Yeah. This is why I look at the smart people in the room as they're reading the slides and wondering if the line is gonna get really long or if this is an easy solution to this fix.

[00:08:08] **Rowan Minahan**: No. Feel free to give a thumbs up if you think this is a fine, acceptable solution.

[00:08:16] **Sean Turner**: We could do a show of hands. I mean, alright. Well, we're gonna go with the thought that if nobody objects, obviously, we're gonna do a working group last call on this again because this is a fairly big change, and it'll give some people a little bit of time to think about this. Also, since this is summertime, we may give people a little more time because Europe goes on vacation in August. So is that cool?

[00:08:38] **Nick Sullivan**: Yeah. Without this change, this draft is not implementable. Yeah. And so I guess the question for the group is, has anybody implemented this draft?

[00:08:49] **Rowan Minahan**: I I know of three implementations. And when I asked around yeah. Go ahead. Rafael, hop up in the mic.

[00:08:56] **Raphael Robert**: No. I mean, I

[00:08:56] **Nick Sullivan**: have your

[00:08:57] **Rowan Minahan**: Okay. Yeah. I I know of three implementations, and when I, like, dug dug into it, one of them basically implemented this. One of them implemented, yeah, one of them implemented SHA three. So, yeah, it's not interoperable if you don't pick one of these. Cool.

[00:09:20] **Sean Turner**: Oh, so I guess

[00:09:21] **Konrad Kohbrok**: question to you. So you

[00:09:22] **Sean Turner**: have this PR, so I feel like what we're set is you've merged this, pop out a new version, and then we can, when needed, start the working class call for this.

[00:09:31] **Rowan Minahan**: We'll see if that will be done in ninety seconds.

[00:09:34] **Konrad Kohbrok**: That's what

[00:09:34] **Sean Turner**: I wanna hear, man. Always be closing. Alright. I believe this is time for Rafael and Konrad.

[00:09:41] **Raphael Robert**: Right? And most extensions. Yeah.

[00:09:45] **Konrad Kohbrok**: Yeah. So there's there's a targeted message.

[00:09:47] **Sean Turner**: The next, yeah, the next slide deck is Rafael and Konrad something one big block, and luckily, it lined up with what I had in the agenda. So they're just gonna kinda rifle through it all.

[00:09:59] **Raphael Robert**: Thank you. Yeah. Yeah. Sorry for the big bug. Yeah. I hope we can go through the more boring drafts quicker because we might need more than five minutes for the Slim MLS part. So, yeah, let's see. MLS extensions. So this one is comparatively easy. Currently, all issues and PRs have been closed and addressed. And last time, the question was how much of that has been implemented, and then I have a quick overview here. So far, I'm only aware of OpenMLS implementing it, but I'd happily stand corrected. So what OpenMLS implements is essentially this part of the draft. There is no obviously, there is no interrupt, but several applications are using this. So since the wire format is not the most important part here, but rather the fact that this works well mechanically, we have some confidence that this part is actually okay to move forward. What we Ron, do you wanna go immediately, speak to that?

[00:11:16] **Rowan Minahan**: I I was just gonna comment on what what's what I know that's implemented with mls-rs.

[00:11:22] **Raphael Robert**: Yep. Please.

[00:11:25] **Rowan Minahan**: Everything on that list except last resort key packages and safe HPK.

[00:11:30] **Raphael Robert**: Okay.

[00:11:31] **Rowan Minahan**: And that doesn't mean that somebody else hasn't done safe HPK in mls-rs. It just we have it.

[00:11:40] **Raphael Robert**: That's good to know. Thanks. And, yeah, what we do not have in OpenMLS at least are these five items. The first four ones are probably very easy to add, and they're very mechanical, and we can just do that. The last one, I wanna ask the authors of that, and I think it's Richard and also Yaron. I'm not sure anymore what the plan is regarding that. So there is no immediate plan to do that in OpenMLS, and I'm wondering where we stand on that if if that is being actively worked on somewhere.

[00:12:15] **Rowan Minahan**: Yep. We had weak multicredential in mls-rs, but it was it it's it's sort of bit rotted. It was it was in a PR and it was in a branch. We tested it, and it was working. Content advertisement is we're we're using and and supported wire formats, required wire formats.

[00:12:39] **Raphael Robert**: Is it something you used to need?

[00:12:41] **Sean Turner**: Is it

[00:12:42] **Rowan Minahan**: It was I mean, it it's something I think we will need for interop at some point. I think something all

[00:12:49] **Raphael Robert**: of us will need for interop. Okay. So it's not something we should drop from the draft? I I would advise against that. Okay. Right. That concludes MLS Extensions. Any more questions on that?

[00:13:05] **Sean Turner**: I guess from a chair perspective, we're gonna continue to wait for the all of these to be implemented then. That's the yeah.

[00:13:16] **Raphael Robert**: Yeah. Okay. So we're gonna take the first four in OpenMLS for sure.

[00:13:20] **Jonathan Hoyland**: Yeah.

[00:13:20] **Raphael Robert**: And then we'll see about multi credential. Fair enough. Okay. Targeted messages. So last time, we discussed expanding that draft in different directions and discussed it a little bit. And so this is essentially just a recap of that. We looked into whether we want to allow external senders. And so, a, there was not a lot of interest in that. And, b, mechanically, would completely change how things work because right now, we use some secret state from the group to inject that as a PSK and HPKE. So it's not just, you know, having a simple enum there, whether the sender is a member or external. There's not a lot of overlap. So long story short, if anybody's interested, this could be a separate draft. There was also the question whether we want to compose this specifically with the PQ-MLS. And the answer, there is no. There's nothing specific to be done. And the last one was, do we wanna have a ratchet that is built on top of this rather basic building block that we have currently in targeted messages? And the feedback there was that it's better to keep it a small building block. If we want more, a, we can do regular two party MLS, or we can build something separate. And later on, we're gonna present on opportunistic channels, actually, which is a separate document. So that's the recap of the discussion. So what has changed in the draft? The ciphertext was not signed. There was an oversight, obviously. We also removed the group context as being part of the HPKE context because we already inject APSK that contains all of that. So we already have that binding, and the group context can be fairly large. And it's it's not necessary to inject that. There was a small circular dependency, which is always fun. So the way we use the AAD and HPKE means we cannot use the one shot API, so we have to decompose that into the manual steps. For ceiling, for opening, it still works, though. We now have test vectors in the draft, and then there were some smaller editor and mechanical fixes. Yeah. So what's next? Working group last call, I think, would be next. I think there is one open issue from Ron who proposed, like, sending targeted messages to multiple recipients, but there's more discussion needed because it's not entirely clear how that would work and if that still fits with the idea of having a a very small building block. Any feedback on that draft? Deafening silence.

[00:16:27] **Sean Turner**: Well, I mean, so we have a few other things queued up already to your working group last call. So I I hope we can let that that conversation continue between you and Rowan about doing that while we're doing the other ones. And then maybe we're done with the other three working group last calls. I I will check back with you to see where we are with this one to get it out the door.

[00:16:46] **Raphael Robert**: Alright. Sounds good. And, Konrad, you're next.

[00:16:55] **Mark Baugher**: Right.

[00:16:58] **Konrad Kohbrok**: So virtual clients was last time, this was essentially freshly adopted by the working group, and it's been in a state where the kind of the concepts were clear and we merged two drafts and agreed on a solution on how generally to do this. Since then, we have implemented this in OpenMLS and found a bunch of things that didn't quite work as we initially thought or at least like a few stumbling blocks where you had to take different things into consideration and add bits and bobs here and there, which we did. I'm sorry. To recap, what is virtual clients? It's a mechanism that allows multiple MLS clients to jointly run, like, a more like, a virtual MLS client. It's virtual because it doesn't correspond to any individual, like, device necessarily, and it's useful for multi device messaging. So for example, if you have, in your application, you have the concept of a user, you want that user to, control multiple devices, then those devices could then jointly operate one MLS client, and that client can then be, part of multiple groups. And if you do it that way, you don't, for example, you don't leak to the rest of the group what device you're using at the moment. But you can also it's also conceivable to use it in other scenarios such as, I don't know, you have a help desk and you have multiple clients that are jointly operating this help desk, but you want that help desk to be its own kind of client and appear only once in a group or something. And it also like, if you have an application where lots of users have multiple clients, then this can also actually make MLS a bit more efficient because it reduces the overall number of leaves in those kind of higher level groups. Yeah. What changed? We've implemented it. Lots of smaller and larger changes, although nothing conceptual. And but I think the draft has matured quite a bit. So this is a good time to engage with the draft if you find this interesting. It would also be great to do interop if anyone else is interested in implementing this. I'd love to get some more assurance that we actually implemented this correctly. So, yeah, I'm looking for comments as well. I don't think this is ready for last call just yet, but I think we're in a good way. And, yeah, feel free to read and let me know what you think. Or let let us know what you think, rather. Just yeah.

[00:19:39] **Sean Turner**: Just keep I'm answering my. Let's keep going.

[00:19:41] **Konrad Kohbrok**: There are no questions. I'm just gonna keep continuing with the two party profile. We also talked about this last time. What is this? This is essentially a describe a way describing a way on how to use MLS if there are only two group members that makes it easier to do a few things. For example, you don't need a, like, a any infrastructure to do the delivery service that that you need to for the group members to agree on the ordering of commits. So you have essentially the draft just describes how the two clients can agree on how they how the commit ordering works, and then you don't need a server to to do any ordering for you. And this is interesting because it allows to use MLS as a kind of drop in replacement for secure channel protocols or any other protocols that involve just two parties. And what we've specified in the draft is how you can do connection establishments, key updates, and resumptions, so stuff that you might know from protocols like TLS, for example, or QUIC. And, yeah, the draft is still in relatively rough shape. We got some good feedback. There's the state machine for this, the key exchange kind of state machine isn't quite complete. So yeah, we want to fix this. But other than that, draft is relatively simple. And I think when once we've ironed out these few kinks, then they should be in pretty good shape. Why are we doing this? There is some interest from members of the like, there was a, I think, more of a family mailing list that's resulted in the current buff that's later today. There was a lot of interest from folks who wanted to use MLS in these two party protocols. And we've also specified how to compose MLS with TLS record layer as a kind of drop in replacement for the TLS key exchange, which again is useful in some scenarios. And, yeah, we've actually, like, implemented that and works quite well in production. One question would be, like, that we've come across again with these issues with the state machine is whether this should stay like a profile that just tells you how to use vanilla MLS or if it's okay for this to become like an actual component or extension, which is a bit more which is heavier, a I guess. Gaetan?

[00:22:09] **Gaëtan Bisson**: It's another question I have. So if you want to finish first, it's fine.

[00:22:13] **Konrad Kohbrok**: I I think I'm pretty much in the end. And but by way, yeah, gave the the feedback on the state machine, so thanks at this point.

[00:22:20] **Gaëtan Bisson**: Okay. Thank you. So we we did an implementation of the draft at SandboxIQ. I guess the most relevant question I have is we've realized there's a lot of protocol that that I initialized with PSK. And I I was wondering if it would make sense for the two party profiles to also define how to do PSK derivation so that integration with lots of protocol is really seamless.

[00:22:48] **Konrad Kohbrok**: Yeah. I I think that's that sounds that's certainly doable. And if you have a use case for it, then we should do it. And this also kind of answers the question because then we probably should introduce a component for this because this allows us to do, like, proper key separation. But, yeah, good good point. If you wanna do PR or just file an issue on the draft, I'll be happy to take a look. Jonathan?

[00:23:10] **Jonathan Hoyland**: Jonathan Hoyland for Tejas. How does this interact with virtual clients?

[00:23:19] **Konrad Kohbrok**: That's a very good question. Have not thought about, to be honest.

[00:23:23] **Jonathan Hoyland**: Because then you've suddenly got multiple endpoints with the same key state. Because because the reason MLS with TLS came up, you know, many years ago was because people wanted to use it for interception of TLS. So pairing this with virtual clients suddenly starts to look very much like an interception use case.

[00:23:46] **Konrad Kohbrok**: Yeah. I have again, like, I haven't thought about this very deeply, but you could probably use virtual clients to, for multiple clients to jointly run a client and then use that client to do a two party profile to to be the the key exchange portion in a secure channel protocol. So, yeah, you could probably do that. Yeah.

[00:24:07] **Jonathan Hoyland**: We should probably make that not happen then.

[00:24:11] **Konrad Kohbrok**: Well, I mean, you can are you saying, like, we shouldn't adopt this draft because it's a possibility? I mean, the specification is in the draft.

[00:24:18] **Jonathan Hoyland**: Like, I'm I can't

[00:24:19] **Rowan Minahan**: take that back.

[00:24:20] **Jonathan Hoyland**: We we should just say you you well, I I personally, I think we shouldn't have an invisible way of doing interception of TLS one three, but that's just a personal opinion, I guess.

[00:24:32] **Konrad Kohbrok**: I I think the I think the TLS working group soundly rejected the notion of putting MLS, like, in the actual TLS key exchange. So I don't think anyone wants to do that with TLS itself. If you can you you can certainly do it outside of TLS if you really want to do that,

[00:24:51] **Rowan Minahan**: But then

[00:24:52] **Jonathan Hoyland**: it's not TLS. Pairing with the record layer then. Anyway, a thought.

[00:24:59] **Rowan Minahan**: Hey, Rowan. So I read the draft. I I think before before adopting it, I would like to see, some, you know, some minimal way of signaling or negotiating that you are gonna use it because I think if you've got a library that can if you've got a library that's intended as a generic MLS library, it should be really obvious that, like, oh, I'm in this mode. And I'd like to make sure that we've got the sort of some answer to the question of, like, when do you decide that you there there there are a couple places where it says you wait more or less indefinitely for, like, some step to complete. Like, to make sure that that, you know, that that we have a little bit more words on that. And and finally, it would be great to have some references to the to the documents in TLS and and, you know, other documents that are using this, like, and and the the document in TLS. Thanks.

[00:26:03] **Konrad Kohbrok**: I this is another pointer that we should probably make this a component, which would then solve this negotiation case, I think.

[00:26:10] **Rowan Minahan**: I don't I don't think we can actually make this a component, but my my talk about extensions and, like, how we generically negotiate things, I think we can we can talk about it in there if we have time.

[00:26:24] **Konrad Kohbrok**: Sure. Sounds good.

[00:26:27] Speaker 8: Yeah. Thank you for the presentation. So there is one question I I I I was asking recently myself around this profile. It it is whether it is possible to move from a two party profile to a multi party situation, or or or do we need to to modify the draft to make that possible?

[00:26:58] **Konrad Kohbrok**: Good question. So this was kind of on the to do list. Like, we didn't do it because we didn't know if there was any interest necessarily, but I don't see any reason why you couldn't upgrade a client from a two party case to a multi party case. But this would then probably need more some way of signaling that you're doing that, and so this would need some more machinery, and you would have to adjust the state machine a bit. If if you're interested in doing that, I'd be happy to take a look at a PR or discuss how we could do this. Sure.

[00:27:28] Speaker 8: Okay. Thank you.

[00:27:31] **Jonathan Hoyland**: John, for Tejas. Sorry. I'm just paging in all of the conversations we had about this in 2018. The the thing that we found difficult when pairing MLS with TLS was that TLS doesn't have whatever the opposite, an importer an a a defined importer interface. So there wasn't an an an understood by TLS way of injecting keys and understanding what those keys were from or how they were derived or, like, how do I know if this was from MLS or whether it was just a PSK or whether it was you know? So that was the the bit that was complicated. So, yeah, I I haven't I haven't had a chance to go through your draft because I only heard about it, like, twenty minutes ago. But, yeah,

[00:28:25] **Konrad Kohbrok**: dragons. Fair enough. Like, if there are concerns, I'd again, I'd be happy to discuss. Maybe we can take this offline if you want. Sure. K, Tom?

[00:28:37] **Gaëtan Bisson**: Yep. So when when I was implementing the draft with the mls-rs library. I thought I thought it was a bit awkward to have different parties have different credentials, like the initiator having the basic credentials and responder x five nine because the same piece of code was used to verify both your own credential and the other party's credential. So I had to work around the API. And I was wondering, is that specifically a problem with the libraries interface at the moment, or it's a limitation of the standard?

[00:29:18] **Konrad Kohbrok**: Brian is probably more qualified than me to answer that question.

[00:29:21] **Rowan Minahan**: I I think that would be a great use of the weak multi credential. If you I mean, you should be able to say what credential you require what type type of credentials you require. And if you require a or b, then you put a weak multi with a and b, and you're good to go.

[00:29:40] **Konrad Kohbrok**: Yep. I'm not entirely sure I understand that use case. It would be super helpful if you could write it in an email or make it a GitHub issue or something. But, again, I'd be happy to look at it.

[00:29:55] **Sean Turner**: Go ahead, Brett. Yeah.

[00:29:56] Speaker 9: Sorry. Thank you for this, excellent draft. So right now, obviously, we could do a two party version of MLS today, but this probably enables some optimization over just the generic two size of group two, basically. And, you know, we use signal and other types of messengers as a two party variance today. So I'm wondering what optimizations this is giving over having just a size two group in MLS.

[00:30:26] **Konrad Kohbrok**: So right now, we we don't really optimize MLS itself. We just use vanilla MLS. And the the thing this draft implements is just, like, again, how these two clients agree on how to order commits and when to accept and when to reject. Optimizations, we can certainly take a look at. I think the big like, the the the things that where it gets difficult is if you use PQ Ciphersuites because then everything that's suboptimal gets really expensive. And I think, at least partially, we can address this with a slim MLS draft that we're present in a in a minute if we have time. But other than that, again, like, I'd be happy to look at optimizations there. But then we'd stray from vanilla MLS, and this would become more involved, I think, depending on how you wanna optimize. Okay. No more if there are no more questions, I think we should move on to some MLS.

[00:31:26] **Raphael Robert**: Thanks. I think time wise, we have a little more time than that doing the math on what's left.

[00:31:32] **Sean Turner**: Yeah. Yeah.

[00:31:33] **Raphael Robert**: Okay. Good. It's reassuring. So who here has read the draft? That's not a lot of people. Okay. I suspect it as much because it's a it's a big draft, and it's not immediately clear by just glancing at it, what it is about. So I want to motivate this a little bit more in detail. So when we did MLS initially, we said two things. We we wanna have two properties. One, we wanna have sublinear scaling for larger groups, and we want it to be ready for PQ. And the answer to that in the end was TreeKEM. So tree, you know, with a binary tree that gives us sublinearity and chem means we can just do PQ, and then we're done. Right? But at the time, we did not really consider because it was, you know, before the NIST competition was over, etcetera. We were not quite sure how big things would actually get with PQ, and we never optimized for that. So the status quo is that we think we don't have optimal efficiency for PQ MLS. And why is that a problem? So if we look at three cipher suites here, the MTI, a mixed one where we use ML-KEM, but we still use traditional signatures, and then the most expensive one we currently have in the PQ cipher suite drafts. And then we look we take, as an example, a group of 1,000 members. Why 1,000? Because this is, I believe, the maximum you can do in Signal and WhatsApp currently. So it is actually a meaningful number, and MLS should be able to support that kind of group size. So here, we can see a welcome and a commit. So the welcome contains a Ratchetting tree. Of course, we can also submit that separately. We know that. But for simplicity, we we have it in the welcome right now. And so a welcome for a thousand member group gets really, really large, as you can see, compared to the the base one with the MTI. And for commit, it's similar in in terms like, we are talking orders of magnitude here simply because we have these larger objects now in the ratcheting tree and the update path. So why is this a problem? A a quick recap for people who are not dealing with secure messengers on a daily basis. The architecture that is common to, I wanna say, almost all secure messengers that, you know, have a a typical client server setup and work on mobile phones. So when client a sends a message to client b, that goes through a delivery service, and then client b only gets a push notification if that's a mobile phone that does not really contain the message itself. It's rather there to wake up client b that is then gonna go back to the server and fetch a queue. And the queue is typically ordered in MLS because we have to order commit messages. So that means client b is gonna do some background execution, And that is heavily limited on iOS and also somewhat limited on Android. It's an environment where you have you don't have a lot of execution time. You have a limited amount of RAM. That community is not really documented by Apple. So you sort of you have a, I think, a reduced stack size as well, so you have to be really, really careful what you do there. And since commits have to be ordered, that means that you're kind of stuck if you do not manage to download megabytes potentially of commits because then you cannot decrypt subsequent messages. So we also know that WhatsApp and Signal, for example, they try to optimize things so that messages ideally fit into the MTU. So the whole idea of just setting ML-KEM and then the most recent iteration there is so that there are no bottlenecks and users can get their messages easily. So by now, you should be able to see why this is actually a problem with MLS if we have these large objects. And so what we thought we can do here is we can start optimizing things. We replace large objects by hash references and simply because we don't need all of them. So currently, with commits, for example, we send a lot of things that are not needed by all of the recipients, and we're gonna look at that in more detail. But we still need to agree on what everybody sees, so we still need the hashes. Then we also actually drop some of the signatures that are not needed. For example, a commit with an update path right now has two signatures in the same message with a large overlap on on what is being signed there. So we thought we could make this one signature. The same goes for batches of key packages that have a lot of signatures. And so the whole thing also complements the MLS combiner draft, which is a PQ MLS rather nicely. So if we look very quickly at the structs, so commit can have this update path, which is required in most of the cases to actually get PCS, and that's that's what's big. And an update path, in turn, has a list of nodes. And as a receiver, you only need one of those nodes. You don't need the rest of it. So that's a starting point. And then the nodes, are are big. So if if we zoom into that, we like, technically, the most expensive cipher suite, we have we have kilobytes per node here. So replacing that by hashes makes it a lot smaller. And then the same is also true for the leaf node. A lot of large objects in there that we don't need all the time. So for example, a commit with an update path has a fresh leaf node even though we have not changed the signature key at all. But we still retransmit it, and there's actually no need for that because everybody already has it. So long story short, there's a very mechanical part to this where we replace a lot of the structs, essentially, with hash references inside wherever there's a large object. And so just to situate that compared to other drafts that are also being discussed. So there's partial MLS that also aims at making things more efficient. And so slim MLS is not there to replace that necessarily. So first of all, on the security side of things, and Konrad is gonna get into that in more detail later, but essentially, with partial MLS, the the whole idea is that you do not verify who's in the group initially. You might do that later. You might never do it. With SlimMls, we do not touch the whole idea of authentication. Then partial MLS works for both classical and PQ server suites. It doesn't really make a difference there. SlimMls is clearly focused on PQ server suites. It's we'll see that later. It's not really very meaningful for just classical Ciphersuites. And then, essentially, the ratcheting tree is is what Partial MLS optimizes, whereas Slim MLS tries to optimize everything that is large. And so you could what you could do with Slim MLS is you could, you know, forget accidentally forget to download signatures and verify them, and that mechanically gives you partial Mls in a way. This is not what we are proposing here, but just as as you know, for your mental model of how these two things compare. So this would be a way to make them quite similar. And then there's also the split commit strut that is gonna talk about later. And so the question there so our initial instinct was, yeah, we should actually maybe join the two, but it turns out that's that is actually not necessary and not necessarily a good idea either. So the Server Aided MLS draft is great for classical cipher suites as well. Again, SlimMls is really focused on PQ. And the the way this works mechanically is that Server Aided MLS is, like, very specific to just the commits. And, again, SlimMls is looking at all the large objects, and how the delivery service assistance works is a little bit different between the two as well. So, again, SlimMls is not here to replace Server Aided MLS if there is a good use case for Server Aided MLS. And I think, Konrad, you're up next. So this is gonna be the more interesting part, actually.

[00:41:09] **Konrad Kohbrok**: Thanks. So now that we've replaced all the large objects by references, clients still need to get hold of the corresponding large objects. Right? So if I download an update path, I still need to get hold of the ciphertext that I need to decrypt to be part of the the group after the commit. And there are three ways that the draft specifies that you can you can get hold of this these larger objects. One is a large objects carrier. That's kind of the the most simple one. Essentially, if you whenever you send an MLS payload, you send also kind of attached to it a large object carrier that's completely unsigned, and that contains all the large objects that you have for which you have references in the MLS payload. And, again, it needs to be doesn't need to be signed because you have these references in the actually authenticated MLS message. The second one could be that you don't actually locally need these large objects because you already have them in a cache. Say you're in two groups with and with a subset of participants, then you probably don't need the signature keys of these participants. You also you already have them in your local cache. You also don't need the credentials because you already have them. And yeah. Ted?

[00:42:31] **Ted Hardie**: Ted Hardie. So just a a a clarification question, if you don't mind. For the large object carrier sent along alongside the message, in this instance, you are not having the same constraints that you would in the push message case that was earlier, or you do?

[00:42:51] **Konrad Kohbrok**: You mean because the payload then grows with the

[00:42:55] **Ted Hardie**: Well, so in the in in the motivation, you were describing the the issue that you're you're given on on both Apple and Android with a relatively small capacity in that. For the large object carrier, are you facing the same capacity constraints or not?

[00:43:10] **Konrad Kohbrok**: Yeah. So this this depends a bit, and this kind of brings me also to to the point I should have mentioned. So rough largely, what this this draft, the separation between reference and large object gives you is flexibility. And so you, as the application who implements MLS, you can now decide whether it's whether you want whether you have a smart server in the middle who knows, oh, this client actually needs these large objects and this client doesn't have this one, so I need to actually send it in a large carry in a large object carrier. So, yeah, the the constraints apply for the objects that you actually need to send. So if I and we'll get to an example later. If I need to fetch my queue and I I download all the messages and then I figure out, oh, I'm actually I'm missing this one large object, then I need to request it, and then it's part of the time that I need to execute.

[00:44:06] **Ted Hardie**: Okay. So I get the the cache and I get the fetch, right, as as separate things because the those are constrained in different ways. Yeah. For the larger object carrier, I I guess my mental model here has has this problem. If the point is that whenever you send the message, you're adding this piece that's a large object carrier that contains all of the large objects. You you now have the same constraints you did before aggregated to the fact that it's now an aggregation of all those large objects, plus now you need to do the verification. And that seems like it's going to be a net loss, and maybe you can explain why it's not.

[00:44:44] **Konrad Kohbrok**: Yeah. Good. That's a that's a good question. Points to something I failed to mention is that you will, in most cases, like or, again, like, if you have a a server that can that has informations about the client state, the server will only send the large objects in the carrier that that client actually needs.

[00:45:02] **Ted Hardie**: Okay. Okay. So there's no dependency on on this state sharing between the two in order for this to be useful. Okay. I think that that should probably be a little bit clearer in how this is described, but thank you very much for the description.

[00:45:14] **Jonathan Hoyland**: Yeah.

[00:45:14] **Konrad Kohbrok**: Good point. And, again, like, it depends on the situation whether you actually need the large object carrier or what you can push or what you can what you want to put in the large object carrier and whether you need, like, a smart component in between or whether it's obvious from the context. Ron?

[00:45:31] **Rowan Minahan**: Yes. So kind of riffing off of what Ted said. So the worst case scenario would be a welcome where none of the members of the you know, none of the people in the Ratchet tree were people that you had previously interacted with. And there, it's actually you know, it's quite complicated figuring out in what order you need to go and process those things. However, the limit I I believe the limit is actually a 128 megabytes for the NSC. And so it is basically impossible to process a whole welcome, but you could process bits and pieces of this aggregated state. If you got the order right, then you could process these in in discrete chunks that are still within the size that's required to handle. Or you could at least send some kind of a message where you could pop up to the user to say, you've been invited to a group, a a large group. You need to go to the foreground for you to be able to to start using this this this messages in this group.

[00:46:40] **Konrad Kohbrok**: Also, potentially, you don't have this kind of stage sharing between the server and the client where the server knows what the client needs, You could also just have a an add an additional round trip where the client gets the message and then figures out, oh, before these references, I I don't have the payloads, so I request them. Of course, that's an additional round trip, more complexity, etcetera. But depending on on the application, this becomes an option if you use this draft.

[00:47:02] **Ted Hardie**: Yeah. Sorry for not clicking the thing again. I I think that's basically a case of fetch, and I I I understand fetch perfectly. I I really do think the what Rowan was explaining that this gives you an opportunity to to maybe order them and send them in a series. That would be great to add as a a part of the description.

[00:47:21] **Konrad Kohbrok**: Okay. Cool. Thanks for the feedback. I think I need to speed up a little bit. So, yeah, I think we just discussed this. You you can, for example, just download the stuff that you need or just send the stuff that you think the other party needs. And this gives you advantages in search so you don't need to duplicate duplicate stuff that you, for example, use across groups. And you also benefit from catching up after you're if you're offline for a while. So for example, if I'm offline for a bit and I have thousands commits, I'm I I only need to download the thousand commits, but I don't need to download every public key that I derive for each of these commits. Instead, I only need to download in the end the public keys that I actually need after I've processed the mass commit. But we'll get to a nice graph in a second. I'll just skip over those for a second. Okay. So what does this actually give us? So here's a graph. And you can see, like, with the MTI CipherSuite, that's not PQ. This is actually a net overhead, as Ted pointed out, because you have to transmit the references and the large object carrier. It becomes actually quite a nice benefit. Again, sorry, we're looking at the welcome size here. If you don't look at the if you have a PQ draft with traditional signatures, then this reduces the size of a welcome drastically. And the size of the welcome here is determined mostly by the public keys in the tree. And each individual MMS member doesn't actually need all the public keys in the tree. You only need the public keys in the co path because to those, you will then want to encrypt your key updates. And this gives you significant size savings. If you look at the PQ Ciphersuites with a PQ signature, the benefits aren't as large because you still need to fetch all the signatures and the leaves, and that's just a big chunk because signatures are just large. And also the the signature public keys as well. Where it gets more interesting is with commits. And here, we now differentiate between commit upload and commit download. Commit upload, you can see the difference is not that big. Again, with the MPI Ciphersuites, we actually have a bit of an overhead. And here, also, the non signature Ciphersuites, non PQ signatures Ciphersuites, have a bit of an overhead. With the with the large signatures, this time, we have a bit of a benefit because if you send an an update commit and you don't change your signature key, then you don't need to retransmit it. And if you have a large credential as well on the leaf, you have, like, a big chain of x five zero nine credentials, maybe with public keys and signatures in them as well. And if that doesn't change, you also don't need to retransmit it, which can be a benefit in some cases. It gets interesting in the download case because here, now, this is kind of emulating a little bit what Server Aided MLS does as well, where each individual recipient then only has to download the stuff that the recipient actually needs. For for example, if I'm in a thousand member group and I have a bunch of ciphertext in the in my update path, each individual member only downloads the ciphertext that it needs, and the other ones, it downloads but only as references. And like this is the catch up case I mentioned earlier. I'm just going to skip over this due to time. So yeah, what's next? The draft is still pretty fresh. We already had some great feedback here, so thank you for that. If you're interested in this draft, nothing. We really need something like this. If it's not this, we need something like this for MLS to be useful with BQ because otherwise, the payload sizes just are out of control. And, yeah, if anyone like, we haven't implemented yet, but we are planning on implementing it. So if every anyone is interested in implementing it, we'd love to do some interrupt testing as well. And, eventually, would be great if the working group were to adopt this document.

[00:51:14] **Sean Turner**: Okay. I think there's one more opportunistic channels. I think what we're gonna do is we're gonna ask you to sit down, and we'll go on. If we end up with time at the end, we'll come back. Otherwise, the information is there to go on the guy. I just wanna make sure we get to everybody else too. Sure. Alright. Thanks. Alright, Mark. You're up next.

[00:51:30] **Mark Baugher**: Hey, folks. And slides.

[00:51:37] **Sean Turner**: It's being shared. Come on, scruffy.

[00:51:40] **Konrad Kohbrok**: This one.

[00:51:41] **Ted Hardie**: Yep. Yep.

[00:51:42] **Sean Turner**: Alright. Just just say next when you're ready.

[00:51:44] **Mark Baugher**: Thank you. So this is, distributed decentralized uses of uses of MLS. Next slide. Background on this is that there's been a lot of interest in deploying a lot in, decentralized, circumstances. Two ATFs ago, there were two drafts, that were presented, and, we got some feedback about why do we have two drafts. And this is us coming back with, combined guidance for the both of them. Slide, please. So what is this draft, in comparison to the others too? The the two drafts that were discussed were independent technical proposals that didn't have a whole lot of overlap. And so it didn't sense make sense to bind those under common authorship or line. However, I think it was correctly pointed out, as an adopter, you want to survey the landscape. You wanna figure out which approach is correct for you, and there was, overlap in surveying how what challenges exist in vanilla MLS deployments and how, in the end, the two different types of approaches take different resolving them. So what resolved out of this is instead of having the docs have pointers to each other and or references to each other and duplicate some of this, it was appropriate to have a single disambiguation doc that presents the shared analysis and guidance for adopters, and then doctors can go find their, deployment. Next. So this is just a summary of what is, in this combined draft, the divergent approaches, all the authors in the room, to answer it. But when net SHAKEs out that, there's a variety of this, maybe confusingly named, decentralized

[00:53:37] **Joel Alwen**: MLS,

[00:53:39] **Mark Baugher**: the prior work of Joel, Marta Mularczyk, and Jannis Rutenbeck, is a good fit for large federal deployments where you have help in resolving state forking. And then there's another approach where a distributed MLS, which, emphasizes local state and is suitable for smaller it's a linear scaling. It's not as efficient, but it's suitable for, places where you expect high level of working or transport age.

[00:54:14] **Nick Sullivan**: Mark, you're cutting in and out. We didn't get the last couple words.

[00:54:21] **Mark Baugher**: That is that's it. Any questions?

[00:54:26] **Sean Turner**: So as a chair, I wanna thank the sets of authors for getting together. It was a bit of a struggle at at first, but then we're like, oh, we can do this. And Mark spent some time with me, and he explained that this should all kind of, like it could kinda kinda work together, or at least the office could work together to explain all this. I do thank you for that. I wanna take it who's read this draft? Oh, it's actually more than I thought. That's, like, five or six. That's pretty good.

[00:54:51] **Brendan McMillion**: So It's a short

[00:54:52] **Sean Turner**: that's really great. So I think the the the way forward here is to see if we can get more people to discuss it on list. See my comment earlier at the beginning of the session about getting on the mailing list and sending email. But I'd like to try to figure out how we can move both of these forward with this document as kind of a way to make sure that it kind of explains to the ISG when they get it and they go, oh, they look the same and they're not. So that's kind of the the plan going forward. Okay? Sound good? Alright. Cool. So I had nod.

[00:55:20] **Raphael Robert**: What time is the Server Aided MLS?

[00:55:22] **Sean Turner**: Server Aided MLS is server aided in loss. Joel.

[00:55:38] **Joel Alwen**: Hey, everybody. So this is I'm gonna tell you about Server Aided MLS. This is a new draft. Well,

[00:55:49] **Ted Hardie**: actually, it's

[00:55:49] **Joel Alwen**: not that new. It's been around for a bit. And it's essentially addressing the bandwidth question as well. So how can we reduce bandwidth for MLS? That was a really nice comparison to Slim MLS. Basically, the idea is okay. Here we go. Alright. So

[00:56:11] **Nick Sullivan**: And the clicker is on now.

[00:56:14] **Joel Alwen**: Okay. Right. So okay. So our goal is to reduce the receiver download on a commit. Okay? So, again, we're looking separately for uploads and downloads, and we don't wanna impact security or functionality or anything. We kinda wanna preserve everything about MLS that we care about. And, also, this is yeah. It's not specific to PQ or anything. I mean, this works really for any any any kind of Ciphersuites. And so this started from the observation that in a typical MLS commit packet, which tend to be, like, sort of a very expensive in terms of size, they include many HPK ciphertext and public keys, and so you end up with a big packet, especially if you're gonna do a PQ Ciphersuites. Right? And so there's three observations here that lead to this draft or something like this draft. The first is that no receiver of any commit will ever decrypt more than one of those ciphertexts. Right? So the packet contains a ton, but any given receiver only decrypts a single one. Typically, receivers also can actually rederive some of the public keys that are on this update path on their own. And MLS is often deployed with an intelligent DS, like a server, basically, right, who can which can process, modify packets, serve up individualized packets for different receivers. So if we pull these three things together, the basic idea that, you know, this draft captures is that we wanna upload everything because somebody needs every one of those ciphertexts. Somebody needs every one of those public keys, but then deliver to each member only the one ciphertext they actually care about and the public keys that they couldn't derive on their own. Right? So so that's what we're our goal is with the draft. But there's a catch. It's not entirely straightforward because MLS also one of the key properties we want is agreement. Right? We wanna make sure that everybody that all clients in an epoch agree on the entire state of this epoch. Everything that yeah. They just agree on everything, including the history, actually. And so how does MLS go about doing that? Well, it signs all the HPK, in particular, in a commit. There's a bunch of mechanisms involved, but we're focused on commits. So in a commit, the sender will sign all the HPK ciphertexts and the public keys. And then later, you feed all these ciphertexts and public keys into the new key schedule. Right? So one observation that sort of opens the gate to how this this draft works is that MLS is really forcing agreement on more than we really would care about at the application level. The keyword being maybe the coins on the HPK ciphertext. We we don't really need agreement on that, but we are because we're signing the actual ciphertext itself. So we're gonna change a little bit, like, how we think about this agreement property, and we're gonna add two words, which is all clients in an epoch should agree on everything that matters about the epoch. Alright? So for those of you that are familiar with sort of a little bit more esoteric crypto literature, this is a bit like the relaxation from CCA to RCCA. Right? We realized that CCA is sort of this this encryption security property that we wanted for secure channels. We realized it was actually going too far. It was doing more than we needed, and we could relax it and still get what we wanted from a secure channel. So we're that same paradigm is what this draft does for MLS. MLS would be the CCA version. This draft relaxes it to our CCA. So how does it work? How does the draft itself work? It introduces a couple of key new data structs around how you you know, that feed into how you construct a commit. Most importantly, there's the it's called the s header, which contains the proposals, the commit leaf node, and the confirmation tag ident confirmation tag. And this is indeed signed by the sender and mapped if it's an MLS public message or encrypted with an AED if it's a private message. Right? So we have everything that MLS does, we're still doing here. But we're separating out the update path. Right? We're putting that into a separate data struct, the s commit, which has the s header in it, but it also has the update path. And, crucially, this is not gonna be signed or MAC'd or anything. And what that enables intuitively is that now you don't need to download everything in this packet anymore because there's no signature over the entire packet that you have to check or any MAC or anything like that. And so what that allows for is that the DS, once it has this entire s commit, you know, represented as a packet, it can modify that and create individualized commits, which will still contain the entire s header. But from this update path, it only contains exactly what that particular receiver needs. Right? So it's maybe one step further than what SlimMLS doing is specifically for this aspect of the update path, if I've understood correctly, because in SlimMls, the receiver would download a bunch of references for stuff that they for the entire update path and only find get the big object for the one thing that they cared about, for example, for the HP. Whereas now, they're not even downloading references anymore. They're just downloading directly the one object that they needed I mean, the one ciphertext they needed. That's kind of the idea. So it's much more much narrower than SlimMLS, but in that, that's kinda how they compare here. So one might think, but there's okay. Well, what about authentication? Right? What about agreement? We're not we're signing less. Why is that not an issue? Well, it turns out that we're still authenticating the Ratchet tree because the Ratchet tree, the new Ratchet tree, is you know, feeds into tree hash. Tree hash feeds into the key schedule, and then we're forking something off the key schedule, a confirmation tag, or we actually use something called a POC identifier, which is pretty much the same thing, one less MAC required. That's it. So

[01:02:05] **Konrad Kohbrok**: that's that's kind

[01:02:05] **Joel Alwen**: of the core idea. This is based on SACK. If you, you know, are curious about sort of the some in-depth security analysis. SACK was a paper a couple years back, stands for Server Aided-tree Chem. I think that's what

[01:02:19] **Ted Hardie**: I don't know why we went with the k.

[01:02:22] **Joel Alwen**: It in relative to the SACK paper, you know, the draft is sort of, like, what we'd actually all the extra bells and whistles we'd need. So it supports proposals. SACK didn't have that yet. It's more streamlined from a maybe a coding perspective. So the s header, the logic of how you would take this s header and turn it into an actual packet is almost the exact same as you would with the commit data struct, so you can use the exact same code for that. We also use an epoch identifier instead of the confirmation tag, which is really just a value forked off the the new key schedule instead of doing the MAC thing. Didn't didn't really add anything to do to do the MAC. And we support public and private MLS wire formats in this draft, which is also not in SACK. There's a caveat here. Kinda curious what people think about this. In the private format, we didn't actually encrypt the update path elements, right, the ciphertext and the public keys. It's a choice. We didn't see the value in doing that. One could encrypt them individually. It adds a bit of bandwidth, adds a bit of compute. We just didn't see the value. That's why it's not in the draft. We're open to push back in any direction. Yeah. Something to look for. I think that's it.

[01:03:44] **Sean Turner**: Alright. We do have some time for questions. Anybody have any? I'm looking at the implementer. Sorry. I got the wrong glasses on. We're good? Alright. Alright. We got twenty minutes of allocated agenda time and thirty minutes left. So, yeah, go ahead.

[01:04:15] **Nick Sullivan**: Okay. Hello, everyone. I'm usually behind the seat here, but now I'm presenting. This is a proposal for a new MLS extension, safe extension, to allow for larger messages effectively. The target use case is attachments, but it it's really just larger messages. This is a relatively short presentation, so, hopefully, the it it doesn't go too far. Okay. So the general idea here is that right. The general idea is that you can take a large object and split it into segments and encrypt each one of those segments and do so in a safe way. There was a recent paper that came out that specified what's effectively a new cryptographic primitive called random access authenticated encryption with additional data. What it does is it basically rather than working on one large file and doing an authenticated encryption on that, it it takes segments of files or segments of the data and encrypts each one of them separately. So one of the things that's really interesting about this construction is that you can compose an existing AAD with a KDF and get yourself an AE sorry. RA AE for very large files. Right? Okay. And so why is this important? Well okay. So the importance is that, well, large files, you can't process them in one go with a a large AEAD. If we're talking about very, very large attachments, you can do streaming. There's all sorts of things. But oftentimes, there's going to be seeking involved in looking through these large files. The receiver may not want to decrypt the entire file and may want to access randomly inside of it and still have a commitment that what they've decrypted was what was sent and encrypted by the, by the sender. So, as you can see, this is sort of very, very analogous. The AED takes the key in the body, spits out output and tag. RAE is basically the same shape. It takes a c e k, content encryption key, and then your your data. And then depending on how you lay it out, you can have your segments at various sizes or constant size along the way. So how do you take something like this and put it into MLS? Well, one of the aspects of the RAAE that wasn't specified in the paper was having a authenticator for the entire thing, something that binds the ciphertext commitments together into one object. And in in the extended RAE, which is proposed in a spec that I'll be talking about on Thursday in a side meeting, you have this concept of a authenticator. And this authenticator, there's various ways to con construct it. The very simple one, you you could imagine, would be just a KDF with a key derived from your CDK over the hashes of all of your segments. That's the the very simple one. And so this, snapshot authenticator will sort of bind all of your segments encrypted segments together. And what you can do is with this identifier is just put it in the place of where the where the message would be in NLS in so in frame data. So rather than encrypting your assigned data, you encrypt this header, the the snapshot, and that binds this large encrypted object with some metadata at the front to your session. And so how does this work with the mechanics of of safe extensions? Well, there's an export secret. You basically export your state, and then you have a key. You can do this. The difference between this and messages is that it is keyed, like, all safe extensions to the epoch rather than to a ratchet that goes forward. So your forward secrecy lifetime is dependent on that. This is not necessarily set in stone if it you if this is something that wants to be pulled into the into the protocol. But, regarding safe extensions, this is the way to do it. There's also an object ID, which, is a locator for the object. There's some options in there if you want to specify this as deterministic, but, typically, this will be a random value that won't collide. And and yeah. So there's a there's a lot of ways of implementing an RAAE. I I have a document that I'm also presenting on Thursday that implements that describes one such composition framework for taking a KDF and AAD and getting an RA AE. It's called Seal. It's very configurable. But in the document, I also list out a a couple different instantiations of it that include not only the fixed size of the segments, which requirements you have for the nonces, and and which requirements you have for the snapshot. So the one that was that we laid out here was optimized for attachments up to a 128 gigabytes. This is pretty big for an attachment, but it seemed like a reasonable bound, and a lot of the the levels fell out from this. And so one of the interesting things here is if you create a two level tree of okay. So in in RAE, the encrypted data is not just encrypted with one key. There is another idea of an epoch similar to MLS, but different such that the first to the end segments are encrypted with one key, then the next with the next key, etcetera, etcetera. The way it's laid out in, in in the encryption is that there's a metadata, which is effectively a hash of your ciphertext, and you have all of this, and it's all lined up in order. And then for each epoch, there's, again, another hash of all the elements of the epoch, and this forms a epoch-ary tree of two levels. And so with this, it actually relatively low bandwidth to get the the hashes that you need to reconstruct an inclusion proof for any segment. If in in this configuration, it's 64 kilobytes, it is imagine that's your basic read size, then it would take one read to full fill the top of the tree, second read to fill your entire epoch. And then from that, you can validate any segment within within that's within that segment. So well, within that epoch. So if you want to arbitrarily decrypt halfway through a movie or if you that's an attachment or a very large file or you want to basically do any random access reads, you can do so with this. And so this is just a very early draft. I think there's a lot of things that are can be moving here. Seal is not finalized. It's very, very early. And we again, I mentioned we can we'll be talking about it later. But effectively, I want to check with the group. Rafael Rafael and I have are working on this draft and wanna see if this idea of the confidentially confidentiality lifetime being tied to the epoch rather than ratcheted is a big deal or not. And if anybody else is interested in using this extension for attachments or other large MLS messages.

[01:13:28] **Ted Hardie**: Ted. Ted, Hardy. Thanks very much. I, as as you know, was only trying to get this this read Yep. During the session here, so I haven't thought about it as long as I should have. In a bunch of parts of the ITF, we've used chunk transfers for a long time. Yep. And chunk transfers encoding with encryption is kind of the mental model for this when you're getting the whole object over over the course of time, and and that I get, I think, pretty well. What's problematic for me in in understanding a little bit about this is the use cases where their randomness is is a required property. And in many of the cases that we have large objects, as you say, like a movie, where you want to start in some portion through the movie, what we have is a manifest. And so what you're actually retrieving is something where the manifest told you where in the object you need to start or what the set of things in in the object are. That manifest can be at the beginning of the object or can be completely delivered separately. Yes. And in the in essence, in this situation, the problematic part of that is the manifest is gonna have to tell you not just where it is in the object, but where it is in the encrypted object according to this epoch. Yes. And the derivation of that is gonna be kinda problematic.

[01:14:46] **Nick Sullivan**: It's very, very simple.

[01:14:48] **Konrad Kohbrok**: Okay. At least

[01:14:48] **Nick Sullivan**: in this format.

[01:14:49] **Ted Hardie**: That what I don't understand.

[01:14:50] **Nick Sullivan**: It's some basically, number of the size of your metadata times the number of segments. So the the this is this is used for complete objects, not incomplete objects that are fully streaming. Right?

[01:15:04] **Rowan Minahan**: Got

[01:15:04] **Nick Sullivan**: that. And there's number of different ways of doing layout with very simple geometry. I I I mean, we're talking about just size of block times

[01:15:15] **Ted Hardie**: I think it wasn't clear enough. Yeah. I I once once you get the the mapping, I I think I understand what you're trying to do. It's like the the process of saying, okay. Here I have an h two six five multilayered video codec, which I'm now gonna send in this this object to somebody. I, as the the person who wants to make it available, need to create a manifest that says, here is where in this encrypted object these layers of this movie at this time are. And the creation of that is gonna be a lot of work for the the person who's doing the creation of the manifest. It's not like Dash where I can just say, you know, once you got the TLS done, it's it's this this part of the the thing on. It it how much time do you think we're gonna get for every epoch to make it worth recreating the random access part of it?

[01:16:18] **Nick Sullivan**: So I I think your question is not about this draft or about this particular serialization of our AE. There's different ways of of splitting this up. This is talk this is basically a serial file. We're not talking about encrypting different chunks within another set of media. That is enabled in SEAL. SEAL's very flexible with respect to layouts. But, with regard to MLS and MLS extensions and particularly, SEAL attachment, it is a a very static layout. And so, fetching within a file is deterministic. And so if you want if SEALs meant to be used in other use cases, I think we can talk about that in another meeting.

[01:16:56] **Ted Hardie**: Okay. I'll I'll go and Yeah. Figure out what meeting I should be in.

[01:17:00] **Rowan Minahan**: Hi. Ron and A. I think this is really cool, and I think it has nothing to do with MLS. So I'd like to dispatch this somewhere else. But I think, like, the specifically, the frame content, like yeah. I think in practice, I I think I would like to see I am skeptical. I'd like to see an existence proof that you would actually wanna send this as a as a, you know, MLS private message with the this in the frame content. I think which because how you would actually deliver, you know, deliver the mess you the I think the whole point of this is you don't want to deliver the whole the whole attachment. You wanna deliver an like, the attachment from a

[01:17:52] **Nick Sullivan**: particular person. Shared location? Exactly. Right. So for example,

[01:17:56] **Rowan Minahan**: you could have what you might send in a, you know, in a private message would be a, you know, a mock URL or an HTTPS URL where you and then you you provide the manifest that allows you to go and figure out how do I get to what what portion of this and how do I decrypt it. But it Yeah. I But I don't think like, you're we're you're using MLS, but then, like, the interesting stuff here is not anything related to MLS or an MLS extension. It's just I got a label. Sure.

[01:18:34] **Nick Sullivan**: Yeah. I I think yeah. That that's that's a very good point. I think the epoch or sorry. The object ID is meant to connect you to whatever type of transcript you want. And at the end of the day, seal, I don't think, belongs in MLS, and it's it's referenced from this document. I I think this this it's a discussion for a different venue. So I I agree with you mostly.

[01:19:01] **Ted Hardie**: Brendan?

[01:19:05] **Brendan McMillion**: Hi. I I think this work is really cool as well, and I wanna see it move forward. I raised my hand because I actually think that it kind of is MLS work. So we've kinda been talking on the mailing list a little bit about the difference between encryption and sign and sign and then encrypt. And MLS, as a protocol, has already adopted the sign and then encrypt pattern, and there's a lot of good reasons for that. But, you know, because it's signed and then encrypt, we have to say how we're gonna assign the data that goes into the separate segments. And so that's I think because RAAE is asymmetric primitive, the MLS work is saying how we're gonna assign the the segments that it gets sent into RA AE, if that makes sense. So I think this potentially is MLS work. I don't think it's a lot of MLS work. Like, most of the work is gonna be defining the actual, like, seal primitive, but I think there is MLS work here to do.

[01:20:06] **Nick Sullivan**: Yeah. To to summarize some of the exchanges Brendan and I had, thank you for engaging with us, Brendan, other folks for reading it, is he was proposing things like signing each of the epoch heads. And so that would be an MLS message with a bunch of signatures, and then you could potentially do some of the really fancy signature things that we've been talking about all day today to, compress that down Or just throw EC DSA or EC, yeah, DSA on everything. Alright.

[01:20:37] **Rowan Minahan**: Thank you.

[01:20:41] **Sean Turner**: Alrighty. You're up in the last ten minutes. I'm not gonna start a timer. Manager, you got

[01:20:48] **Rowan Minahan**: ten minutes

[01:20:48] **Sean Turner**: for stuff.

[01:20:49] **Rowan Minahan**: Okay. Couple couple ITFs ago, I presented this.

[01:20:53] **Sean Turner**: It's an iShart.

[01:20:54] **Rowan Minahan**: So does your extension work with another extension? That's a kind of a hard problem to answer. Right? So I I figured out this table by reading every one of these documents and thinking about what kind of extension they were and how they work with other extensions, and do they conflict? So getting extensibility right in general is it's kind of a it's an art and a science. But I think this is something that we need to do as a as a working group that's starting to get into the phase where we've got, you know, dozens of dozens of proposals and dozens of extensions. So the first thing that I wanted to mention is that we really need to make sure that we are using the most the most appropriate tool, which often in this I think should be the least disruptive tool possible for the job. So I I picked an example. So there's a document that was draft for MLS additional wire formats, which was designed to allow for implicit out of band AED. So good idea. It defined two new wire formats. A wire format is a massive sledgehammer. So this was, like, basically, like, putting a putting a one meter squared hole in your in your concrete wall to kill a mosquito. It unfortunately, defining a new wire format for this meant that you couldn't use this with with a targeted message, for example. You couldn't use it with a semi private message. Right? Because then you would have needed to define another wire type, another wire format type that that pair that mirrored this. So I wrote up an example alternate mechanism. It if you want if you wanna have a look, it's there. But, basically, this is something I I did in in, like, twenty minutes. This is an single extension to signal support of out of band AAD. And then there are two components that you actually use to to signal what AAD goes out of band. So this is the kind of this is the a way of kind of refactoring something that a a good idea and trying to make it as late as possible so that it's as com compatible as as possible with the most things. And, you know, honestly, we've already done a pretty okay job if there's many green things in this table as there are. But it but, honestly, a lot of that is by accident and just by the fact that MLS is pretty flexible and is a pretty good protocol. So couple of big themes here. Lots of things that we've been working on are related to efficiency, particularly in large groups, More security properties, like we're gonna we need to address protection from insider attacks. It's one thing. Improve the PCS. We wanna talk about how we generate secrets in other places where we may need them. For example, for seal, for r a a d r r a a e? That's just seal. Seal. There's there's lot there's interest in efficiently targeting subgroups. So for example, opportunistic channels. I have a wish list item, which is to be able to have an in group encrypted part of the group context. That would be lovely to have. I think that'd be a nice generic thing. I don't know exactly yet how to do that, but I think we could probably figure that out. Then we also have, you know, reduced metadata, improved privacy, and then other places where we want to use MLS. For example, this some of these two party scenarios, the IKE the IKE profile or use case. Okay. So we also have in addition to these kind of, like, the topics, we also have domains where we end up wanting to apply these things. So, fortunately, there are a lot of these extensions that apply kinda universally that we could use in any of these. You know, you're not gonna use a targeted message in in a in the two party profile, but, you know, largely, virtual clients, targeted messages, racket tree, new new credential types, new content type. Like, the a lot of the things here, they apply in in several of the of the environments. You may say, for example, that, like, SlimMls, it was designed more for this large group smart DS or heavy DS that uses public handSHAKEs, but it doesn't have to be that way. And so, like, trying to expand our view when we're when we build an extension to see, well, how do we get some functionality that was designed for, you know, public message commit DSs to work in private message commit DSs, for example. That that's that's an exercise I'm just trying to encourage people who are designing extensions to consider. So on the other side, like, for private message commits, we don't actually have a lot of of extensions that we have that we have built over there. I worked on one with for private external commits. Konrad did the remove intents, which you could apply here, which actually would be quite a useful feature there because it would allow some policy stuff. So let me talk a little bit about a a blend. So we have this notion right now of, you know, we build a lot of big services that have large large groups with public public handSHAKE DSs. Now there's a lot of policy stuff that you wanna be able to do. There's some enforcement. There are some things like being able to force removes. Some of this stuff we could actually do in groups that have private private commit. And we would need in order to do something like that, we would need to do for example, let's say we have a private message. We have a commit. Then we might need to have something. Let's say that we were using something like Mimi. So we had Mimi room policy and participants and roles. So we could for example, we could take deltas, changes that we made to a participant list or to a list of roles, and we could send those to the to the DS in the AAD or in an encrypted blob that's encrypted to its to its public key. And then we could have some commitments or proofs that are in another AED component that we could use to to demonstrate particular properties that we wanted to prove, but without revealing all of the gory details that are in the Ratchet tree. And I I I want us to to really be able to, you know, think, can we get can we get here? Right? Because we do have people who are deploying systems that rely on private commits. We definitely have plenty of plenty of services out there that are using public commits. If we want to interrupt between those two between systems, if we wanna federate between a system that uses public commits and one that uses private commits, we're gonna need to come up with a way to do to solve some of these problems. And that's when, know, that's when we're gonna have sort of an an application of MLS that is true that is truly exercising our the negotiation features that that we have.

[01:29:07] **Sean Turner**: Questions? So I have one from the chair. So you mentioned federation the federated MLS one, which has been expired for a long time. Are you thinking about trying to work on that to bring it back so that we would actually be able to solve all the Scare problems?

[01:29:23] **Rowan Minahan**: Well, we have another federation document that's called Mimi protocol that is also currently in frozen. So I think the we have a chicken and egg problem of needing imp you know, wanting to have some interop between implementers and having specs that can be implemented. So if you're interested in doing interop with or without Mimi, if you're interested in doing federation of some application, please come and talk to me. You know, come and talk well, come and talk to any of us that are, like, that right extensions. Right? But I'd love to hear from folks that are actually implemented in that interested in that.

[01:30:10] **Sean Turner**: Alright. Cool. We are out of time. We did have two presentations that didn't make it. So efficient frame content to be signed was not discussed yet, but is there, and opportunistic channels also. Please go ahead and read those drafts and take the discussion to the list. Remember the first part of the session. So thank you very much. Thanks, Eric, for taking notes. Do you wanna

[01:30:53] **Ted Hardie**: yeah.