[MLS] Re: -02 DMLS Draft

["Hale, Britta (CIV)" <[e-mail]>]

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]>