]>

rohan.ietf@gmail.com

Security Messaging Layer Security external commits pending proposals The Messaging Layer Security (MLS) protocol allows authorized non-members to join a group via external commits, however it disallows most pending proposals in those commits, which causes unfortunate side effects. This document describes an MLS extension to include pending proposal in external commits when the extension is present in a group. 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 MLS allows external commits by authorized clients. The external committer needs a copy of the GroupInfo, either from an existing member or (when supported) from the MLS Distribution Service (DS). The reasoning was that the external committer can't access pending proposals, and that the external committer could not verify them in any case. The problem is that two important use cases are negatively impacted when external committers join: leaving a group, and external policy enforcement. This document describes an MLS extension, that when in the required_capabilities in the GroupContext, requires an external joiner to include any pending proposals by reference in its external commit. It assumes that the external joiner can get a suitable set of external proposals from whichever party supplies the GroupInfo.

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 relies on many terms and struct names from .

Problem Use Cases

Leaving a group MLS clients cannot leave a group without the assistance of another member of the group. A Remove proposal, or SelfRemove proposal (see ) needs to be committed before it takes effect, but a client cannot commit its own remove, because a committer knows the epoch secret for the newly created epoch. Instead, a leaver sends a Remove or SelfRemove proposal and then stays in the group it is trying to leave until it receives a commit showing it has been removed. The client will not be able to determine the epoch secret of the new group, but it will be able validate the tags of the commit. If an external commit is accepted by the DS before a Remove proposal is committed, the leaver needs to enter the new epoch and try to leave again. In practice, this can happen multiple times before the leaver's proposal is finally committed. The SelfRemove proposal addresses this problem partially, in that SelfRemove proposals can be included by reference in an external commit, however this does not solve the problem when there are related proposals that should be processed atomically. When the leaver wants all the clients of the same "user" identity to leave simultaneously, it has a dilema. It can commit Remove proposals for all the user's other clients, then send a SelfRemove proposal immediately in the new epoch. Alternatively, it can send a bundle a proposals for itself and the user's other clients, but risk that only the SelfRemove proposal is committed (at which point the leaver cannot effect any other changes to the group), or that several epochs pass before all the leaving clients are removed. This problem is exacerbated in the More Instant Message Interoperability (MIMI) protocol () since the removal of another client may not be authorized by itself, but would be otherwise acceptable when a user is removing itself completely.

External policy enforcer In many architectures, an external policy enforcer can send external proposals to an MLS group. This could be relatively simple, as in an organization removing a compromised client, or a company removing the clients associated with an employee when she leaves the company. In more complicated scenarios, such as in MIMI room policy , the policy enforcer might change the role of a participant to ban them, to prevent them from sending messages, or to remove their moderator privileges. If an external commit occurs after the pending external proposals, the commit would usually exclude the pending proposals. The policy enforcer would have to resend the external proposals in the new epoch. A malicious client could try to send an external commit to rejoin the group immediately upon seeing a proposal to lower its privileges. The DS could refuse the external commit, but the participant would still have legitimate use cases where it may need to rejoin via an external commit. A pair of malicious clients, A and B, could collude so if B sees an external proposal removing, banning, or reducing privileges of A, B sends an external commit. B could potentially delay the policy action against A by several epochs using this approach.

Mechanism This document defines the external_pending_proposals extension type. When present in the capabilities of a LeafNode it indicates the client's support of the extension. When present in the required_capabilities in the GroupContext, it indicates that all clients MUST include all the pending proposals provided to it by the provider of the GroupInfo. The external_pending_proposals extension type has no contents: The provider of the GroupInfo is expected to provide all the pending proposals it has received at the point it provides the GroupInfo.

Security Considerations

Authentication of Proposals by Potential Joiner If the source of the GroupInfo provides an invalid proposal, an external commit using that GroupInfo and proposal list will be rejected by the other group members. This is effectively a denial of service attack on the client that wants to join the group. However the source of the GroupInfo could more easily not provide the GroupInfo, or provide an invalid one. This problem could be eliminated if the external joiner can authenticate the request. This is already the case for most external proposals, which are typically used for policy enforcement. describes a mechanism by which leavers can prove their intent to leave and, at the time, their membership in an MLS group.

Authentication of Proposals by a policy enforcing DS A policy enforcing DS can validate most proposals and commits. A malicious or faulty client can generate an incorrect tag or an invalid UpdatePath without detection by the MLS DS, regardless of this mechanism. Most of the proposal types in can be validates by a policy enforcing DS, however a proposal that members could determine was invalid, but a DS could not could lead to exactly the same types of problems already observed with faulty commits.

IANA Considerations This document requests the addition of a new MLS Extension Type under the heading of "Messaging Layer Security". RFC EDITOR: Please replace XXXX throughout with the RFC number assigned to this document The external_pending_proposals MLS Extension Type is used inside GroupContext and LeafNode objects. When present it indicates support for this extension.

• Value: 0x0009 (suggested)
• Name: external_pending_proposals
• Message(s): GC, LN : This extension may appear in GroupContext and LeafNode objects
• 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. Phoenix R&D The Messaging Layer Security (MLS) protocol is an asynchronous group authenticated key exchange protocol. MLS provides a number of capabilities to applications, as well as several extension points internal to the protocol. This document provides a consolidated application API, guidance for how the protocol's extension points should be used, and a few concrete examples of both core protocol extensions and uses of the application API. Rohan Mahy Consulting Services This document describes a set of concrete room policies for the More Instant Messaging Interoperability (MIMI) Working Group. It describes several independent properties and policy attributes which can be combined to model a wide range of chat and multimedia conference types. Informative References 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 The Messaging Layer Security (MLS) protocol defined in [RFC9420] is an asynchronous secure group messaging protocol, which allows group members to propose their own removal from a group. However, in some cases MLS clients can't reliably use regular Remove or SelfRemove proposals to leave a group because they don't have an up-to-date group state. This document specifies a LeafOperationIntent, which does not need an up-to-date group state but which retains sufficient binding to the client's current state to avoid replay attacks.

Acknowledgments TODO acknowledge.