| Internet-Draft | DDMLS | June 2026 |
| Xue, et al. | Expires 28 December 2026 | [Page] |
The Messaging Layer Security (MLS) protocol provides continuous key agreement and offers additional benefits in multi-device group use cases. MLS relies on a Delivery Service (DS) for message ordering. In highly centralized uses, where the DS is a single server, configuration is straightforward. However, MLS also lends itself to use cases that are decentralized (e.g., federated networks) and even distributed (e.g., mesh networks). This informational document lays out uses of MLS and its variants and extensions across various topologies and provides guidance on selection among alternatives under both functionality and security considerations.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://germ-mark.github.io/mls-informational-decentralized-applications/draft-xue-mls-decentralized.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-xue-mls-decentralized/.¶
Discussion of this document takes place on the Messaging Layer Security Working Group mailing list (mailto:mls@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/mls/. Subscribe at https://www.ietf.org/mailman/listinfo/mls/.¶
Source for this draft and an issue tracker can be found at https://github.com/germ-mark/mls-informational-decentralized-applications.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 28 December 2026.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The Messaging Layer Security (MLS) protocol is typically used in scenarios where a Delivery Service (DS) layer ensures that clients eventually agree on the order in which commits are applied. However, MLS is increasingly used in decentralized and distributed environments such as mesh networks. In such cases, implementation of an adequate DS that ensures agreement on commit ordering can be difficult, for example, because it incurs a significant overhead. This has driven consideration of how to account for potential forking of the group state [I-D.kohbrok-mls-dmls] for reordered commit messages or avoid the risk of out-of-order commits altogether [I-D.xue-distributed-mls]. This informational document provides an outline of uses of MLS and its extensions across various network topology considerations, with specific considerations to network overhead, storage, and security from state forking.¶
Members: Protocol participants. Centralized: A centralized network has a single server or entity perform the responsibilities of a DS. An entity may also be a member. Decentralized: A decentralized network relies on federation of servers or select entities performing the responsibilities of a DS. For example, assigned members may coordinate DS responsibilities among themselves. Distributed: A distributed network relies on many entities performing the responsibilities of a DS. This may include cases of many members or even all members participating in DS responsibilities, such as in mesh networks.¶
The MLS protocol is defined in [RFC9420].¶
MLS offers logarithmic overhead for groups.¶
Additional overhead from the DS must also be accounted for.¶
The centralized case is straightforward in MLS. For decentralized use cases and distributed use cases, care must be taken to identify a suitable DS to ensure that there is group consensus on commit ordering. As a use case increases in complexity from the decentralized setting to the distributed setting, DS design decisions have increasing implications on overhead and potentially also security.¶
In a decentralized setting, one example solution is to assign one server (among a set of federated servers) as the decision holder for such ordering, thereby creating a pseudo-centralized environment out of a decentralized environment. In a distributed use case, the challenge increases. Similar temporary role assignment to members, where one member is dedicated as the "lead" entity for deciding commit ordering may be possible in well-connected use cases.¶
Another approach is hierarchical ordering of commits, e.g., where each member is assigned an order in which to commit a PCS update. This eases the complexity of the DS, but can create considerations on length of PCS windows, especially if a member is offline. Handling of Adds and Removes must also be accounted for.¶
Yet a further approach is that of using a consensus algorithm to reach agreement on commit ordering. This offloads overhead to the DS as such consensus algorithms can vary widely in overhead and delay incurred for processing, especially if a member is unreachable.¶
Thus maintaining consensus on commit ordering tends to incur increasing DS overhead as network topologies become more distributed.¶
MLS is heavily dependent on commit ordering being processed in the correct sequence. Out-of-order commits can lead to forks in the group state.¶
In MLS, retention of a group state after applying a commit is strongly discouraged, because it compromises the protocol's forward secrecy. As such, clients cannot process out-of-order commits, because the group state is deleted after the first commit is applied.¶
DeMLS [I-D.kohbrok-mls-dmls] is a variant of MLS that achieves fork resilience as introduced by Alwen et al. [FRCGKA], which significantly improves forward secrecy when retaining a group state after applying a commit.¶
The main difference between MLS and DeMLS is how the init_secret is derived in
the key schedule. Instead of a regular KDF, DeMLS uses a puncturable
pseudorandom function (PPRF), which prevents the client from deriving the same
init_secret twice, thus achieving forward secrecy for each specific commit.¶
As DeMLS is largely the same as MLS, it retains its performance characteristics with the exception of local storage. Here, the PPRF used by DeMLS incurs a local storage overhead on the order of 10 kB (depending slightly on the PPRF implementation) per commit processed (if the old group state is retained). The only other place where DeMLS differs from MLS is that an extra 32-byte epoch identifier needs to be attached to every message to identify the exact group state required to process the message.¶
Its fork resilience makes DeMLS generally suitable for use in environments where the DS cannot prevent the occurrence of out-of-order commits.¶
However, due to the overhead associated with commit processing, DeMLS benefits from a DS that can inform clients when out-of-order processing may be necessary.¶
For example, in federated environments, individual servers can detect when they lose connectivity with other parts of the network and inform clients that they may need to process multiple commits for the current epoch. Similarly, the server can inform its clients when a given netsplit is over and old group states can be deleted.¶
DeMLS makes it safer to maintain multiple forks of a group at the added cost of storage, as well as a slight complexity increase in MLS's key schedule. This makes the use of MLS viable in environments where forks may occur due to out-of-order commits.¶
DiMLS is defined in [I-D.xue-distributed-mls].¶
DiMLS accomodates concurrent actions by * defining a subset of group operations that are commutative and can be applied ou of order * using MLS groups as a primitive to represent each local snapshot of the total group state * advancing group state by distributing commits to the sender's local state * maintaining causal dependency across MLS groups by exporting shared secrets and importing them as PSK's.¶
DiMLS overhead has linear update overhead. However, it is not dependent on the DS for commit ordering, reducing the DS overhead requirements. For example, a consensus on commit ordering is not required for the DS unlike in MLS. Thus the trade-off in DiMLS is among overhead incurred by the security protocol itself and its architectural requirements in DS overhead.¶
In DiMLS there are fewer requirements on the DS for exact ordering. Members must eventually receive each commit from each other member, but delivery does not need to be ordered for members to maintain consistent state.¶
DeMLS is highly resilient to out-of-order commits and, in the case of honest members, forking of the group state is not possible. This is because each member has full control of commit ordering as it relates to the keying state protecting the messages that member sends.¶
The basic MLS protocol functions well in environments where reliable in-order delivery can be assured. That includes both centralized environment as well as those in decentralized and distributed uses where the DS overhead for e.g., consensus is deemed supportable.¶
For cases of minor network topology spread, e.g., decentralized uses such as federated servers, DeMLS can provide improvements to fork resiliency at minor costs to storage.¶
For distributed environments where significant changes in network topologies are expected, e.g., mesh networks, or where memory storage is a consideration, DiMLS offers advantages.¶
This document covers security considerations for various applications of other documents to and including MLS. This document is not an exhaustive security reference for use of MLS in decentralized or distributed environments, but focuses on the issue of state forking in such use cases.¶
This document has no IANA actions.¶