]> Germ Network, Inc.

mark@germ.network

Naval Postgraduate School

britta.hale@nps.edu

Phoenix R&D

Security Messaging Layer Security decentralized mls 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 The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Messaging Layer Security Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

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 for reordered commit messages or avoid the risk of out-of-order commits altogether . 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.

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.

Trade-off Considerations

MLS The MLS protocol is defined in .

Overhead MLS offers logarithmic overhead for groups. Additional overhead from the DS must also be accounted for.

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.

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.

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. DeMLS is a variant of MLS that achieves fork resilience as introduced by Alwen et al. , 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.

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.

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.

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.

DiMLS DiMLS is defined in . 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.

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.

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.

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.

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.

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.

IANA Considerations This document has no IANA actions.

References Normative References Messaging applications are increasingly making use of end-to-end security mechanisms to ensure that messages are only accessible to the communicating endpoints, and not to any servers involved in delivering messages. Establishing keys to provide such protections is challenging for group chat settings, in which more than two clients need to agree on a key but may not be online at the same time. In this document, we specify a key establishment protocol that provides efficient asynchronous group key establishment with forward secrecy (FS) and post-compromise security (PCS) for groups in size ranging from two to thousands. Informative References Phoenix R&D Messaging Layer Security (MLS) provides strong end-to-end security guarantees for group messaging including Forward Secrecy (FS) and Post-Compromise Security (PCS). To facilitate agreement between group members, MLS requires a Delivery Service (DS) component that orders of the handshake messages (Commits) that allow changes to the group state. In decentralized settings without a central authoritative entity to enforce ordering, group members will likely have to retain key material so they can process Commits out-of-order. Retaining key material, however, significantly reduces the FS of the protocol. This draft specifies Decentralized MLS (DMLS), based on the Fork-Resilient Continuous Group Key Agreement protocol FREEK proposed by Alwen et al. [FRCGKA]. In essence, DMLS extends MLS such that key material can be retained to process Commits out-of- order with recuded impact to FS, thus allowing safer deployment in decentralized environments. Germ Network, Inc. US Naval Postgraduate School US Naval Postgraduate School The Messaging Layer Security (MLS) protocol enables a group of participants to negotiate a common cryptographic state for messaging, providing Forward Secrecy (FS) and Post-Compromise Security (PCS). There are some use cases where message ordering challenges may make it difficult for a group of participants to agree on a common state or use cases where reaching eventual consistency is impractical for the application. This document describes Distributed-MLS (DMLS), a composition protocol for using MLS sessions to protect messages among participants without negotiating a common group state.