Distributed and Decentralized Uses of MLS
draft-xue-mls-decentralized-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Mark Xue , Britta Hale , Konrad Kohbrok | ||
| Last updated | 2026-06-30 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-xue-mls-decentralized-00
Messaging Layer Security M. Xue
Internet-Draft Germ Network, Inc.
Intended status: Informational B. Hale
Expires: 28 December 2026 Naval Postgraduate School
K. Kohbrok
Phoenix R&D
26 June 2026
Distributed and Decentralized Uses of MLS
draft-xue-mls-decentralized-00
Abstract
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.
About This Document
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.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Xue, et al. Expires 28 December 2026 [Page 1]
Internet-Draft DDMLS June 2026
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 Notice
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Trade-off Considerations . . . . . . . . . . . . . . . . . . 3
3.1. MLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1.1. Overhead . . . . . . . . . . . . . . . . . . . . . . 3
3.1.2. Delivery Service . . . . . . . . . . . . . . . . . . 4
3.1.3. Resiliency . . . . . . . . . . . . . . . . . . . . . 4
3.2. DeMLS . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2.1. Overhead . . . . . . . . . . . . . . . . . . . . . . 5
3.2.2. Delivery Service . . . . . . . . . . . . . . . . . . 5
3.2.3. Resiliency . . . . . . . . . . . . . . . . . . . . . 5
3.3. DiMLS . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3.1. Overhead . . . . . . . . . . . . . . . . . . . . . . 6
3.3.2. Delivery Service . . . . . . . . . . . . . . . . . . 6
3.3.3. Resiliency . . . . . . . . . . . . . . . . . . . . . 6
4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . 7
Xue, et al. Expires 28 December 2026 [Page 2]
Internet-Draft DDMLS June 2026
7.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
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.
2. Definitions
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.
3. Trade-off Considerations
3.1. MLS
The MLS protocol is defined in [RFC9420].
3.1.1. Overhead
MLS offers logarithmic overhead for groups.
Additional overhead from the DS must also be accounted for.
Xue, et al. Expires 28 December 2026 [Page 3]
Internet-Draft DDMLS June 2026
3.1.2. Delivery Service
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.
3.1.3. Resiliency
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.
3.2. DeMLS
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.
Xue, et al. Expires 28 December 2026 [Page 4]
Internet-Draft DDMLS June 2026
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.
3.2.1. Overhead
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.
3.2.2. Delivery Service
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.
3.2.3. Resiliency
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.
Xue, et al. Expires 28 December 2026 [Page 5]
Internet-Draft DDMLS June 2026
3.3. DiMLS
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.
3.3.1. Overhead
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.
3.3.2. Delivery Service
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.
3.3.3. Resiliency
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.
4. Use Cases
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.
Xue, et al. Expires 28 December 2026 [Page 6]
Internet-Draft DDMLS June 2026
5. Security Considerations
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.
6. IANA Considerations
This document has no IANA actions.
7. References
7.1. Normative References
[RFC9420] Barnes, R., Beurdouche, B., Robert, R., Millican, J.,
Omara, E., and K. Cohn-Gordon, "The Messaging Layer
Security (MLS) Protocol", RFC 9420, DOI 10.17487/RFC9420,
July 2023, <https://www.rfc-editor.org/rfc/rfc9420>.
7.2. Informative References
[FRCGKA] Alwen, J., Mularczyk, M., and Y. Tselekounis, "Fork-
Resilient Continuous Group Key Agreement", 22 February
2024, <https://eprint.iacr.org/2023/394.pdf>.
[I-D.kohbrok-mls-dmls]
Kohbrok, K., "Decentralized Messaging Layer Security",
Work in Progress, Internet-Draft, draft-kohbrok-mls-dmls-
03, 20 October 2025,
<https://datatracker.ietf.org/doc/html/draft-kohbrok-mls-
dmls-03>.
[I-D.xue-distributed-mls]
Xue, M., Lukefahr, J. W., and B. Hale, "Distributed MLS",
Work in Progress, Internet-Draft, draft-xue-distributed-
mls-02, 20 October 2025,
<https://datatracker.ietf.org/doc/html/draft-xue-
distributed-mls-02>.
Authors' Addresses
Mark Xue
Germ Network, Inc.
Email: mark@germ.network
Xue, et al. Expires 28 December 2026 [Page 7]
Internet-Draft DDMLS June 2026
Britta Hale
Naval Postgraduate School
Email: britta.hale@nps.edu
Konrad Kohbrok
Phoenix R&D
Xue, et al. Expires 28 December 2026 [Page 8]