[MLS] Re: -02 DMLS Draft

["Mularczyk, Marta" <[e-mail]>]

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]>
Sent: 22 October 2025 23:48
To: 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: [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]>
Date: Tuesday, 21. October 2025 at 17:06
To: MLS List <[e-mail]>
Cc: Mark Xue <[e-mail]>, "Lukefahr, Joseph (CIV)" <[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]>