]> Rohan Mahy Consulting Services

rohan.ietf@gmail.com

Security Messaging Layer Security ratchet_tree GroupInfo PartialGroupInfo The Messaging Layer Security (MLS) protocol needs to share its ratchet_tree object to welcome new clients into a group and in external joins. While the protocol only defines a mechanism for sharing the entire tree, most implementations use various optimizations to avoid sending this structure repeatedly in large groups. This document describes a way to convey these improvements in a standardized way and to convey the parts of a GroupInfo object that are not visible to an intermediary server. 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 In the Messaging Layer Security (MLS) protocol , the members of a group are organized into a ratchet tree, the full representation of which is described in the ratchet_tree extension. The protocol specifies that the full ratchet_tree can be included in Welcome messages or shared externally, but describes no concrete way to convey it externally. Likewise, when non-member clients want to join a group, they can do so using an external commit. They require the GroupInfo and the ratchet_tree. Many MLS implementations allow external commits to get the GroupInfo from a central server. In the MIMI architecture , this server is called the hub, and for brevity we will use that term generically to refer to any central server that provides either GroupInfo or ratchet_tree objects to new members (i.e. welcomed clients or externally joining clients). When all handshake messages (commits and proposals) are sent as PublicMessages (or SemiPrivateMessages ), the hub can construct its own version of the ratchet_tree and most of the GroupInfo object as proposals and commits arrive.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. This document assumes familiarity with terms and structs from the MLS specification ().

Conveying the Ratchet Tree The ratchet tree can be conveyed inline in its entirety. Alternatively, this document describes how it can be referred to via an HTTPS URI, or signaled that it is communicated out-of-band or reconstructed by the distribution service. ; case httpsUrl: /* an HTTPS URL */ opaque ratchet_tree_url; case outOfBand: struct {}; case distributionService: struct {}; }; } RatchetTreeOption; ]]>

• full indicates that the complete ratchet_tree extension is included in the RatchetTreeOption object.
• httpsUri indicates that the ratchet_tree can be downloaded from a URI using the https: scheme.
• outOfBand indicates that the ratchet_tree is communicated or reconstructed via an unspecified out-of-band application protocol.
• distributionService indicates that the ratchet_tree is reconstructed by the Distribution Service (DS) from the handshake in the group. This is not possible if any handshake messages are sent as an MLS PrivateMessage.

Conveying the ratchet tree using HTTPS This document defines a new MLS GroupContext extension ratchet_tree_source_domains. When present, it contains a list of at least one domain name. ; } Domain; struct { Domain domains } DomainList; DomainList ratchet_tree_source_domains; ]]> When this extension is included in the GroupContext of a group, the URL where the ratchet_tree is fetched MUST come from one of the domains in the ratchet_tree_source_domains.domains list.

Conveying the GroupInfo In some systems the GroupInfo is sent to a hub with a full ratchet_tree extension always included with every commit. This is used in systems where the hub may or may not track the membership of the group, but does not keep the entire ratchet_tree data structure. As group size increases, the size of the ratchet_tree extension in the GroupInfo scales roughly linearly. Even using basic credentials, this object gets large quickly. If x509 credentials are used, the size increases much more rapidly, and if a post-quantum ciphersuite (for example ) is used, the size will increase even more rapidly with each new member. In some systems that require unencrypted handshake messages, the hub tracks commits as they are sent and constructs changes to the ratchet_tree as each handshake is accepted. The hub could also recreate most of the fields of a GroupInfo, with the exception of the GroupInfo signature and the GroupInfo extensions, by inspecting those same unencrypted handshake messages . This document defines a PartialGroupInfo struct that contains these missing fields. PartialGroupInfo can be included with a commit and any referenced proposals to reconstruct a GroupInfo and ratchet_tree from the GroupInfo and ratchet_tree included in the previous epoch. ; opaque signature; } PartialGroupInfo; ]]> The value of ratchet_tree_presence is defined as follows:

• no_ratchet_tree: the ratchet_tree extension appears in neither the current nor previous epochs.
• present: there is a ratchet_tree extension in both the current and previous epochs.
• removed: there was a ratchet_tree extension in the previous epoch but none in the current epoch.
• added: there is a ratchet_tree extension in the current epoch but there was none in the previous epoch.

The group_info_extensions object is the list of GroupInfo extensions, omitting any ratchet_tree extension (if present). The only other GroupInfo extension defined in the base protocol is external_pub, the public key of the external commiter. The group_info_extensions is often an empty list. The signature in the PartialGroupInfo is the signature produced by the committer (represented by its leaf index in the GroupInfo as the signer).

Security Considerations The Security Considerations of the MLS protocol and the MLS architecture apply. The integrity of the ratchet tree is assured using the MLS GroupContext.tree_hash (see ). The tree hash allows the receiver to verify that the ratchet tree is valid whether it is transmitted in the ratchet_tree extension or out-of-band. In some systems such as the MIMI protocol , the DS receives a GroupInfo with each tentative commit message. The DS cannot verify the correctness of a GroupInfo because it does not have the GroupInfo.extensions. This is no different with a partial GroupInfo message. In both partial and full GroupInfo presentation, given a specific GroupInfo.signature, the DS can merely verify that the extensions and the signature are consistent with each other and with the GroupContext.

IANA Considerations

ratchet_tree_source_domains MLS Extension Type This document registers the ratchet_tree_source_domains Extension Type, using the template below:

• Value: TBD1 (new assignment by IANA)
• Name: ratchet_tree_source_domains
• Messages: GC
• Recommended: Y
• Reference: RFC XXXX

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. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. The Messaging Layer Security (MLS) protocol (RFC 9420) provides a group key agreement protocol for messaging applications. MLS is designed to protect against eavesdropping, tampering, and message forgery, and to provide forward secrecy (FS) and post-compromise security (PCS). This document describes the architecture for using MLS in a general secure group messaging infrastructure and defines the security goals for MLS. It provides guidance on building a group messaging system and discusses security and privacy trade-offs offered by multiple security mechanisms that are part of the MLS protocol (e.g., frequency of public encryption key rotation). The document also provides guidance for parts of the infrastructure that are not standardized by MLS and are instead left to the application. While the recommendations of this document are not mandatory to follow in order to interoperate at the protocol level, they affect the overall security guarantees that are achieved by a messaging application. This is especially true in the case of active adversaries that are able to compromise clients, the Delivery Service (DS), or the Authentication Service (AS). Informative References Cisco The More Instant Messaging Interoperability (MIMI) working group is defining a suite of protocols that allow messaging providers to interoperate with one another. This document lays out an overall architecture enumerating the MIMI protocols and how they work together to enable an overall messaging experience. Rohan Mahy Consulting Services This document defines a SemiPrivateMessage for the Messaging Layer Security (MLS) protocol. It allows members to share otherwise private commits and proposals with a designated list of external receivers rather than send these handshakes in a PublicMessage. Cisco This document registers new cipher suites for Messaging Layer Security (MLS) based on "post-quantum" algorithms, which are intended to be resilient to attack by quantum computers. These cipher suites are constructed using the new Module-Lattice Key Encapsulation Mechanism (ML-KEM), optionally in combination with traditional elliptic curve KEMs, together with appropriate authenticated encryption, hash, and signature algorithms. Cisco The Matrix.org Foundation C.I.C. Phoenix R&D Rohan Mahy Consulting Services The Matrix.org Foundation C.I.C. Phoenix R&D This document specifies the More Instant Messaging Interoperability (MIMI) transport protocol, which allows users of different messaging providers to interoperate in group chats (rooms), including to send and receive messages, share room policy, and add participants to and remove participants from rooms. MIMI describes messages between providers, leaving most aspects of the provider-internal client- server communication up to the provider. MIMI integrates the Messaging Layer Security (MLS) protocol to provide end-to-end security assurances, including authentication of protocol participants, confidentiality of messages exchanged within a room, and agreement on the state of the room. Phoenix R&D Phoenix R&D This document describes the MIMI Delivery Service.

Change Log

Changes between draft-mahy-...-04 and draft-ietf-...-00

• No changes except for renaming the draft

Changes between -03 and -04

• Added Security Considerations
• Removed unneeded tree_signature

Changes between -02 and -03

• No changes except for the publication dates

Changes between -01 and -02

• Added ratchet_tree_source_domains extension

Changes between -00 and -01

• Removed ratchet tree patch options and notation.
• Added ratchet_tree_presence options for out-of-band, via HTTPS, and reconstructed by the delivery service.

Acknowledgments The PartialGroupInfo was first introduced in .