[MLS] Re: -02 DMLS Draft

[Mark Xue <[e-mail]>]

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]
> To unsubscribe send an email to [e-mail]
>