[MLS] Re: -02 DMLS Draft

["Alwen, Joel" <[e-mail]>]

I am invested in the best solutions becoming standards. Their origins are irrelevant. Their technical merits are not. Dismissing discourse on the merits as academic is seriously missing the purpose of this forum and does a disservice to the goal of producing better standards. We’re not here to just say “yay / nay” to drafts. We’re also here to understand them, and (possibly) improve them. This working group iterated on and refined MLS for 5 years by constantly and openly discussing the technical merits of different drafts. I fail to see why this is any different when it comes to something as subtle & complex as E2EE in distributed settings.

Case in point: In its current form I do not support Konrad’s draft. As a result of the prior discussion here on DMLS, I now believe that the “copying LeafNodes” techniques from DMLS would also add value to Konrad’s draft and so, barring further insights on the topic, I’d advocate for incorporating it.

If we can’t articulate what makes one technique a better choice than another or what a technique is for then maybe we don’t understand them well enough yet to cement them in stone as an RFCs? A standard being the way it is “because the authors said so” is an exceedingly weak argument IMO. Well-articulated reasoned or empirical analysis are not.

For example:
> FREEK does not support all use cases and has already been considered and discarded
> as a solution in the use cases of the DMLS authors – primarily for functionality but also
> for security reasons (due to lack of causality).

If enforcing causality was truly the deciding technical factor in discard FREEKS efficiency optimizations then maybe that decision should be revisited. The key technique in FREEK (a shared epoch tree) is just as compatible with exporting/injecting PSKs as in DMLS. That is, causal dependences can be enforced to the exact same extent. So, this security goal does not justify, at a technical level, dismissing the efficiency benefits other techniques like a shared epoch tree (split commits or flat ratchet trees) could provide in a distributed setting.

These protocols -- DMLS, FREEK, Split Commits, etc -- are not monolithic incompatible constructions. We shouldn’t be trying to “choose a winner”. Each one, represent bundles of novel mechanisms that can often be combined to get a best of both worlds product. But to do that, we have to dig in to why things are the way they are and ask if they could be different and better.

- Joel

From: "Hale, Britta (CIV)" <[e-mail]>
Date: Friday, 31. October 2025 at 00:13
To: "Alwen, Joel" <[e-mail]>, Marta Mularczyk <[e-mail]>
Cc: "Lukefahr, Joseph (CIV)" <[e-mail]>, Mark Xue <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: RE: [EXTERNAL] [MLS] Re: -02 DMLS Draft


CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.

Joēl,

Naturally you have personal investment in having FREEK used, which I fully acknowledge and recognize as the driver to the bellicose email and previous verbal manner in meeting. To address that root aspect: If it helps as an assuagement, I will note that we (the DMLS draft authors) have no issues with FREEK as a standalone extension and indeed fully support Konrad’s draft on it. I believe that there are many possible uses. It is simply that FREEK does not support all use cases and has already been considered and discarded as a solution in the use cases of the DMLS authors – primarily for functionality but also for security reasons (due to lack of causality).

As those deploying for such environments, functionality matters. If you are also deploying in decentralized use cases, feel explain the topology you are using; comparing and contrasting that with other topologies (e.g., federation vs mesh) will no doubt provide self-clarification on why each of the claims about FREEK being “better” have inaccurate assumption bases and are discounting network operational behavior. Otherwise, as much as academic debate is valuable for its own merit, it really does not change system constraints.

It is clear from tone that further response will not result or be received productively and I am disinclined to engage in a line-by-line argument.


Britta



From: "Alwen, Joel" <[e-mail]>
Date: Thursday, October 30, 2025 at 3:01 PM
To: "Hale, Britta (CIV)" <[e-mail]>, "Mularczyk, Marta" <[e-mail]>
Cc: "Lukefahr, Joseph (CIV)" <[e-mail]>, Mark Xue <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [MLS] Re: -02 DMLS Draft

NPS WARNING: *external sender* verify before acting.

I think (?) I’m starting to better understand what you mean by sender’s having more control over the PCS of (the epochs in which they send) their own application messages…

I like the mechanism of copying LeafNode structs between epochs. It makes total sense for FREEK too. It allows gathering fresh (i.e. healed) keys from *concurrent* epochs. Vanilla FREEK only ever lets me create a child epoch to a single existing epoch. So, if B and C update to healed leaf keys in concurrent epochs I’d have to choose (at most) one of those 2 epochs to build on. Whatever I choose, I am missing out on at least one of their healing operations. But by letting me inject the HPKE keys form *both* of their new epochs into my new epoch, I get to take advantage of both healing operations to *immediately* create a secure epoch (anywhere I want in the epoch tree).  Was this what you meant by having more control?

For the rest of the email I’ll write FREEK* for “FREEK with LeafNode copying”.


> [with DMLS] an insider cannot disrupt the group state

Not following… In a DMLS group with A, B and C, insider A can do a broken commit in her Send Group that only B but not C can process (which is undetectable by everyone without C’s help). As soon as B -- and any other group members -- see the commit, they’ll export/inject a PSK into their own Send Group. C doesn’t know the PSKs and is left behind including in honest B’s Send Group. Isn’t that a split of the DMLS group?

> as a result, forking is not an issue.

What do you mean by “not an issue”? It seems, using DMLS requires either:
  (A) a resolution algorithm when concurrent group actions are taken (e.g. Adds & Removes) or
  (B) a DS that orders things to prevent concurrency.
I think DMLS is aiming for not having (B)? So, resolution is needed. (None of this is DMLS specific. Its true for *any* protocol.)

>  an insider cannot disrupt the group state (hence the analogy to Signal)

The same forks can happen with Signal’s group protocol too. https://ia.cr/2017/713 goes into some ways forks can be used to disrupt the group states for Signal (and WhatsApp). To avoid such disruptions, Signal uses their DS to globally order group membership changes. (https://ia.cr/2019/1416)



I’m gonna go ahead and make what I have no doubt will be a terribly controversial, at best, claim. By all means, explain why I’m wrong if you think I am! I’m certainly not invested in this claim. But I have been thinking on-and-off about this particular topic quite a bit now (years) so I’m also not exactly shooting from the hip either. Just trying to stimulate conversation so we can end up with the best set of standards.

<claim>
FREEK* (i.e. FREEK + LeafNode copying) is as good or better than DMLS in every of the following senses.
1. It has at least the security of DMLS
2. It gives senders the same freedom to control the security of their app msgs.
3. It is more flexibility than DMLS.
4. It is, generally, a LOT more bandwidth efficient than DMLS.

Also, the “Split Commits” technique is orthogonal to everything in DMLS and FREEK* and benefits both protocols by reducing bandwidth with no impact on security or flexibility.
<\claim>

So before anyone jumps on me, let me first give a bit of justification for this claim…

- Security : In general, I think both protocols have MLS-like PCFS properties. I’m not sure the puncturing of init_secrets as in FREEK* adds something over DMLS, but it certainly doesn’t harm.

- Same control of security of sent msgs : In both DMLS and FREEK*, a sender can pull in whatever fresh key material they want from any epochs they’ve witnessed so far. Of course, I can’t heal a receiver of my msgs if the don’t act first (publish a new leaf node somehow). But that’s true for both protocols. So, no difference here.

- Flexibility: Forcing a causal dependency between epochs with a PSK works for FREEK* just as for DMLS. But DMLS is opinionated: it mandates all causal dependencies must be enforced. Instead, FREEK* leaves this open to the application. So, it can be like DMLS, but doesn’t have to be. Why wouldn’t we want such dependency? Because by *not* injecting a PSK, I allow receivers to still process my commit even if they didn’t get some irrelevant prior commit I happened to have seen.
   FREEK* is also more flexible because it doesn’t always trigger a cascade of commits by all other group members the way DMLS does when really, I just wanted to heal myself. Maybe I want to heal frequently, but Alice doesn’t need to?

- Efficiency : I think this is where things REALLY diverge between the different protocols. I’m comparing:
  FREEK*
  s-FREEK* := FREEK* + Split Commits
  DMLS
  s-DMLS := DMLS + Split Commits + Dropping the unused HPKE keys on commiter’s paths.

Consider the download cost (and ignore PSK IDs) of each existing group member in an n-party group…

Adding Alice:
- DMLS         : n^2 ctxts, 2n leaf nodes, n*log(n) HPKE pks.
 - s-DMLS    : n ctxts,  2n leaves
- FREEK*     : log(n) <-> n ctxt, log(n) PKs, 2 leaf nodes.
- s-FREEK* : 1 ctxt, up to log(n) PKs, 2 leaf nodes

PCS healing whole group:
- (s-)DMLS  : same as adding Alice
- FREEK*     : n * (log(n) <-> n) ctxts, n *log(n) PKs, 2n leaf nodes
- s-FREEK* : n ctxts, up to n*log(n) PKs, 2n leaf nodes

The (s-)DMLS estimates are pretty tight lower-bounds I think. It doesn’t get better and we’re ignoring some stuff that also scales linearly (like the PSK proposals telling receivers from which epochs in which Send Groups to be injecting from). But for (s-)FREEK* I erred in the opposite sense. It’s an upper bound on bandwidth. E.g. if some people heal with update proposals instead of commits bandwidth gets smaller. All the way down to 1 ctxt, log(n) PKs and n leaf nodes in the extreme. But that also blanks out the whole ratchet tree so you’d probably not want that in practice.

Incidentally, the same way that copying LeafNodes between concurrent epochs lets committers make more use of prior healing operations, the single epoch tree of FREEK* lets different epochs make more use of past commits *by other parties* to improve efficiency. In DMLS Send Group ratchet trees don’t share internal nodes. So, Alice filling in her ratchet tree doesn’t improve efficiency for Bob’s commits. But in FREEK (and its variants) it might if Alice’s commit is descendent of Bob’s. That’s the root cause for why FREEK has so much better efficiency.

In any case, my point is, DMLS seems the worst for bandwidth, at least for those two operations, from any of the 4 protocols.



  *   Joel




From: "Hale, Britta (CIV)" <[e-mail]>
Date: Thursday, 30. October 2025 at 00:05
To: Marta Mularczyk <[e-mail]>
Cc: "Lukefahr, Joseph (CIV)" <[e-mail]>, Mark Xue <[e-mail]>, "[e-mail]" <[e-mail]>, "Alwen, Joel" <[e-mail]>
Subject: RE: [EXTERNAL] [MLS] Re: -02 DMLS Draft


CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.

Marta,

Below are answers to your questions. If anything is missed or further clarification would help, please just ask. To start, a context on these option under a decentralized use case may be advantageous:

MLS
In the decentralized use case, MLS can still be used, but there are heavy caveats due to the burden on selecting an appropriate DS for resolution. Some approaches include hierarchical assignment of permitted device update order, scheduled update order (where a missed window means a device cannot update), etc. Various transport protocols can also help support that resolution, although with overhead costs (.
Pro: Logarithmic overhead on updates. Con: Heavy management burden on update processing/the DS. Potentially heavy overhead from DS.
Ideal use case: In decentralized environments where the network topology is known and scheduling of updates is not overly complex. If that is practical, then forking is likely avoided and FREEK is unnecessary.


FREEK
For FREEK, the approach is to use more storage to compensate for the ability to resolve some forks. Resolution is still challenging for this as network decentralization increases – an issue that has been played out over several years of research. Such a DS is not defined in FREEK, so there is an inherent open aspect to its implementation. For more minor network decentralization, defining a DS is not too challenging, but for more decentralization it can be. FREEK does not solve the decentralization challenge of strict MLS – what is solves is the FS issue up to a point, enabling processing of more out-of-order updates.
Pro: MLS-style overhead on updates. Con: Storage incurred and resolution is dependent on an undefined DS. Potential overhead from DS.
Ideal use case: Federation environments, especially with many users, where there may or may not be centralization and minor forks can occur.


DMLS
An analogy for contextualizing DMLS is an MLS-based variant of how Signal currently supports groups. DMLS enables a member to broadcast to other members while fully controlling when and how keys are updated for that channel. The aggregation of such sending channels then encompasses the group. Unlike in regular MLS, an insider cannot disrupt the group state (hence the analogy to Signal). This also inherently prevents forks from ever occurring and obviates that issue entirely. There is no shadow overhead from a suitable DS. There is however linear overhead within the update sequence itself as intermediate nodes remain blank for other members than the channel owner.
Pro: No forks even in highly decentralized use cases. Potential DS overhead for resolution avoided. Con: Higher update overhead (no logarithmic scaling).
Ideal use case: Decentralized environments where forking and network disruption is expected, including mesh networks, the search-and-rescue example, etc., especially for small to moderate numbers (not thousands) of devices per group.

In short, these all have different use cases. They are not competing approaches.


----
Other answers
"A can process a commit CB from B if she received all commits B got before sending CB. Is this what DMLS achieves with PSKs?": Yes, in DMLS commits from a given member are ordered for that member just as in MLS.
"How do other senders know that they should add B to their sender groups?": The same way as in MLS.  If a member sees Alice “add” Dave, they also “add” Dave to their own Send Group. It requires an additional commit, but the general process is not much different.
"Does this mean that adding B requires N commits and consuming N key packages of B?”: Yes. Again, DMLS is basically an MLS-based version of how Signal does groups - it has higher overhead, but an insider cannot disrupt the group state and, as a result, forking is not an issue.
"DMLS allows a group member to control PCS for messages it sends. But... isn't it possible with MLS (and FREEK) too?" No. In DMLS a group owner can choose when to inject the PCS update of the other member - which is an incentive to do so ASAP, but the group owner can also delay if bandwidth or other environment constraints force the device into a receive-only mode.  The owner has full control of what protects the data they send (but not what they receive from others). In contrast, FREEK and MLS the group concurrence must always hold. There is not a clear argument for which is better between MLS/FREEK and DMLS on this point; it is highly scenario dependent. There are clear arguments for security being stronger for different options in different threat/update scenarios.

Rescue scenario: "So if any member is corrupted while in the cave, the adversary my use this HPKE key to decrypt the commit secret in epoch 2 (combine it with the init secret leaked by corrupting Alice in epoch 1) and so decrypt Msg. With MLS, on the other hand, that HPKE key would be deleted and Msg would be secure.” The scenario given is unclear, but suffice to say that in MLS, if the HPKE key is deleted, then that member was successfully removed. You can do this with DMLS too. If the threshold timeout for removing a member has not been reached in either protocol use or the remove not received, then you would indeed have old keys that you are using.
Britta




From: Mularczyk, Marta <[e-mail]>
Sent: Tuesday, October 28, 2025 8:48 AM
To: Mark Xue <[e-mail]>; Alwen, Joel <alwenjo=[e-mail]>; Hale, Britta (CIV) <britta.hale=[e-mail]>; MLS List <[e-mail]>
Cc: Mark Xue <[e-mail]>; Lukefahr, Joseph (CIV) <[e-mail]>
Subject: Re: [MLS] Re: -02 DMLS Draft

NPS WARNING: *external sender* verify before acting.

Hi Mark,

Thank you for writing up the DMLS design, it's super interesting :-)  I wonder if you could help me understand how MLS, DMLS and FREEK compare? My main goal is to be able to decide which protocol works best for an application.

Let me clarify first that FREEK does not require eventual convergence (if I understood the latter correctly). FREEK builds a tree of epochs, reflecting causal dependency between them. It simply allows to explore the whole tree (while MLS would allow to explore only one path). An external algorithm *could* decide on a "converged state" implied by a view of FREEK's tree, but this is not part of FREEK.

I tried to compare MLS, DMLS and FREEK in terms of DS requirements, efficiency and security. Here are my thoughts.

==== DS requirements

MLS requires a global order on commits. This can be relaxed to only require a causal order: A can process a commit CB from B if she received all commits B got before sending CB. Is this what DMLS achieves with PSKs? I think that FREEK relaxes this even further: A can process CB if she has the predecessor epoch of the one created by CB in her tree of epochs. This relaxation can be a good or a bad thing (as some causal information is lost), depending on the context. (FWIW one can always enforce more causal dependencies in FREEK as desired using commits with PSKs as in DMLS. e.g. only include PSKs from past epoch that modified the group membership, etc.)

Questions:
* Is there an execution (with an unreliable DS) where DMLS can process a commit and FREEK not?
* What network did you have in mind for DMLS? Is it a mesh network (think, protesters or Bridgefy), or federated applications (like in MIMI), or servers in the field (e.g., search and rescue teams go into different caves).

==== Efficiency

MLS is most efficient. FREEK needs larger local states but as efficient as MLS in terms of communication. DMLS has linear commit cost.

I need some help with understanding the cost of adding someone to a DMLS group. Say A adds B to an N-member DMLS group. This means that B needs to be added to N sender groups.
* How do other senders know that they should add B to their sender groups?
* Does this mean that adding B requires N commits and consuming N key packages of B?

==== Security

The main question I'm struggling with is: Is there an execution with corruptions that differentiates security of DMLS and FREEK? I couldn't find one.

I also have a couple of questions about Security Considerations from the DMLS draft:
* I may be missing something (and it's not a big deal), but I think that both DMLS and FREEK store old HPKE secrets to handle forks. This slightly reduces the FS of MLS, I have an example below.
* If I understood correctly, the rest of the first paragraph says that DMLS allows a group member to control PCS for messages it sends. But... isn't it possible with MLS (and FREEK) too? Before sending a message, Alice can always make an MLS commit including any PCS updates she needs (as update or replace proposals).

==== FS of MLS vs FS of DMLS/FREEK

This is not a big deal but possibly interesting :-) Consider the following execution. It starts with a group at epoch 1 with N members including Alice and Bob. Alice is corrupted, Bob removes Alice, creating epoch 2. Bob sends a message Msg. Now half of the group goes into the left cave and half into the right cave. Each half communicates within itself, which creates two parallel sequences of commits.

To be able to communicate with the other half after leaving the cave, each member has to store the HPKE secret key from epoch 2 (or did I misunderstand and it is not the case for DMLS?). So if any member is corrupted while in the cave, the adversary my use this HPKE key to decrypt the commit secret in epoch 2 (combine it with the init secret leaked by corrupting Alice in epoch 1) and so decrypt Msg.

With MLS, on the other hand, that HPKE key would be deleted and Msg would be secure.

- Marta




________________________________
From: Mark Xue <[e-mail]<mailto:[e-mail]>>
Sent: 22 October 2025 23:48
To: Alwen, Joel <alwenjo=[e-mail]<mailto:alwenjo=[e-mail]>>; Hale, Britta (CIV) <britta.hale=[e-mail]<mailto:britta.hale=[e-mail]>>; MLS List <[e-mail]<mailto:[e-mail]>>
Cc: Mark Xue <[e-mail]<mailto:[e-mail]>>; Lukefahr, Joseph (CIV) <[e-mail]<mailto:[e-mail]>>
Subject: [EXTERNAL] [MLS] Re: -02 DMLS Draft


CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.

Joel, appreciate the collaborative comments as always. Responding in some topical collection:

- Comparing group mutation to vanilla and fork-resilient MLS
If we loosely model members of a group as having ordered leaf node keys over time (k_i_j, where i is index of member in group and j is the ordering of member k_i's leaf node.
    - vanilla MLS advances membership through monotonically increasing j index for each member k_i in a single path of commits
    - (forgive my possible misunderstanding) fork-resilient MLS, within some epochal window of retained derived group init secrets and corresponding leaf node private key(s), allows for divergence of that path, if members go back and process alternate commits, and should converge on a single path.
     - Distributed MLS avoids implicating eventual convergence by letting each member independently choose a path of updating {k_i_j}, monotonically increasing j (through the commits in their send group). In place of eventual path convergence, PSK injection adds a dependency of Alice's path (group state) on everyone else's (locally known to Alice) path (group state). In this way, DMembers cooperatively and retroactively assemble a common history that is a dependency for current send group state(s), without requiring current or future consensus. Put another way, PSK injection ensures that recipients have access to a send group's new group state only if they successfully have access to the dependent epochs in other send groups.

DGroup commits ack DGroup updates, so we have a deterministic floor for when leafNode private keys can be safely discarded. Fairly, in biasing for local action, we then have local inaction (offline or service denial of a member) as a constraint.
The draft specifies one mitigation, by removing the long offline member.

Drawing on your feedback, it may be worthwhile to enable more eager deletion of intermediate (in the j index) private keys if we invert the functional priority for long offline members and require them to catch up to more recent state (as they must anyway to continue processing DGroup messages).

- Implementation
You raise pertinent issues for implementers. While most of the mechanics are implementable outside an MLS implementation, I think leafNode substitution across send groups implicates modifications to an off the shelf library. A possible modification could be a new proposal type, such as described in the replace draft. Your comments suggest to me that a revised commit operation could be an appropriate mechanism for copying leaf nodes across send groups along with optimizations and enforcing other send group restrictions at the MLS layer.

Mark

On Wed, Oct 22, 2025, at 6:44 AM, Alwen, Joel wrote:

Thanks for the updated draft.



I had a couple questions / comments after reading through the new draft. I hope they will be received in the collaborative spirit they are intended.





- What is the purpose of injecting the PSKs from other send groups?



- Are MLS’s update proposals used in DMLS?

- How about adding guidance about when I can delete my old leaf HPKE secret after I send a commit? It’s an availability vs. security trade-off so should probably be balanced (but an implementor focused on availability might miss the security cost of their choices). Keeping my old HPKE secrets longer means I am more likely to be able to process delayed incoming commits but also means I’m degrading the PCS in other people’s sender groups.



- Re: Section 8 “FS guarantees per Send Group follow similarly”: I’m struggling a bit with this… The FS in any MLS group also depends on everyone deleting old secrets. But, for DMLS, when that happens is not under the Send Group owner’s control? (E.g. rotating in a new LeafNode HPKE key for Alice, doesn’t mean Alice will delete her previous HPKE sk because she might still want it to process commits in other people’s Send Groups.)



- Re: Sec. 8 “in DMLS the PCS healing frequency… is controlled by the Send Group owner.” I don’t see yet how DMLS PCFS properties improve on those of MLS. In both cases, Alice can only rotate in new keys for Bob if Bob acts first. Could you help me understand the claim a bit more? How does a Send Group owner have more control over the PCFS of their application messages compared to an MLS group member that is free to (A) commit to pending update proposals and (B) remove stale group members before sending their application messages?



One thing I do see with DMLS vs. MLS is a difference in what risk is created by Bob being off-line for a long time. In an MLS group, Bob’s stale secrets present a risk to the confidentiality of past messages, but only if he is compromised. In a DMLS, Bob’s Send Group stagnates when he’s off-line. So, everyone in the group must keep their leaf HPKE sks around in case he comes back. But those sks were also used to process commits in other send groups. So, now, if any one of their devices is compromised, the confidentiality of old messages could get harmed. Is this accurate? If so does it bear mentioning in Security Considerations?



- Re: Sec. 8 “Notably, since the Send Group….desynchronization of the group view.” Maybe that sentence needs a bit more nuance? What if insider Alice sends a mall-formed commit in her Send Group which Bob can process but not Carl (e.g. his HPKE ctxt was crap in the commit). Next, honest Bob exports a PSK and injects it into his Send Group. Alice can follow to the new epoch, but not Carl. Unless Carl tells Bob, he has no way of knowing this is happening in his own Send Group.



- Where should clients be getting the GID and leaf index from (for the LeafNodeTBS struct) when verifying the signature of an imported LeafNode?



- Would it make sense to add text gathering any changes to MLS needed by DMLS in one place? That would give an implementor a single place to look for info on how they should modify a hypothetical “off-the-shelf” MLS library. E.g. when should I *not* delete my HPKE secrets in DMLS although MLS would? What’s different about validation logic for LeafNode structs in a ratchet tree when join a group or in a received commit?



- What new validation checks (if any) should clients do when they join the DGroup? Is it OK to join a DGroup mid-update? Or should clients expect “consistent” trees? E.g. if Alice’s send group has LeafNode N1 in her ratchet tree, should joiners ensure that’s also her LeafNode in all other send groups?



-  Would it make sense to further change how commits work to strip out the redundant stuff? No HPKE key pair on the sender’s path is ever used except for the one at their leaf. Does it make sense to strip them from the whole commit process to save on compute and bandwidth?



- If the scope includes bandwidth constrained DSs / clients, could it make sense to use something like Split Commits so receivers only need to download the 1 HPKE ctxt in a commit instead of all n of them?





Anyway, thanks for the thought provoking draft. I like the idea of Send Groups and am trying hard to understand how they compare to a fork-resilient approach.



·         Joel





From: "Hale, Britta (CIV)" <britta.hale=[e-mail]<mailto:britta.hale=[e-mail]>>
Date: Tuesday, 21. October 2025 at 17:06
To: MLS List <[e-mail]<mailto:[e-mail]>>
Cc: Mark Xue <[e-mail]<mailto:[e-mail]>>, "Lukefahr, Joseph (CIV)" <[e-mail]<mailto:[e-mail]>>
Subject: [EXTERNAL] [MLS] -02 DMLS Draft



CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.



All,



An update for the DMLS -02 version draft is available (https://datatracker.ietf.org/doc/html/draft-xue-distributed-mls-02) This incorporates all the feedback received since presentation at IETF-122.



As a reminder, this draft covers distributed MLS, where each member has control of messages sent, ordering of commits, and PCS frequency in their own sub-group, thereby avoiding commit collisions altogether, specifically aiming for the decentralized use case. There are two active implementations of this as well since IETF-122.



We would like to have a call for adoption on the draft and of course welcome any further inputs.



Britta







Amazon Development Center Austria GmbH
Brueckenkopfgasse 1
8020 Graz
Oesterreich
Sitz in Graz
Firmenbuchnummer: FN 439453 f
Firmenbuchgericht: Landesgericht fuer Zivilrechtssachen Graz


_______________________________________________
MLS mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>





Amazon Development Center Austria GmbH
Brueckenkopfgasse 1
8020 Graz
Oesterreich
Sitz in Graz
Firmenbuchnummer: FN 439453 f
Firmenbuchgericht: Landesgericht fuer Zivilrechtssachen Graz


Amazon Development Center Austria GmbH
Brueckenkopfgasse 1
8020 Graz
Oesterreich
Sitz in Graz
Firmenbuchnummer: FN 439453 f
Firmenbuchgericht: Landesgericht fuer Zivilrechtssachen Graz