Messaging Layer Security R. Barnes Internet-Draft Cisco Intended status: Informational M. Mularczyk Expires: 9 January 2025 Amazon M. Xue Germ Network, Inc. 8 July 2024 The MLS Replace Proposal draft-barnes-mls-replace-00 Abstract Post-compromise security is one of the core security guarantees provided by the Messaging Layer Security (MLS) protocol. MLS provides post-compromise security for a member when the member's leaf node in the MLS ratchet tree is updated, either by that member sending a Commit message, or by an Update proposal from that member being committed. Unfortunately, Update proposals can only be committed in the epoch in which they are sent, leading to missed opportunities for post-compromise security. This document defines a Replace proposal that allows the fresh leaf node in an Update proposal to be applied in a future epoch, thus enabling post- compromise security for the affected member even if their Update proposal is received too late to be committed. 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://bifurcation.github.io/mls-replace/draft-barnes-mls- replace.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-barnes-mls-replace/. 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/bifurcation/mls-replace. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Barnes, et al. Expires 9 January 2025 [Page 1] Internet-Draft MLS Replace July 2024 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 9 January 2025. Copyright Notice Copyright (c) 2024 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 3. Leaf Node Epoch Extension . . . . . . . . . . . . . . . . . . 3 4. Replace Proposal . . . . . . . . . . . . . . . . . . . . . . 4 5. Proposal List Validation . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 8. Normative References . . . . . . . . . . . . . . . . . . . . 6 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction Post-compromise security (PCS) is one of the core security guarantees provided by the Messaging Layer Security (MLS) protocol. MLS provides PCS for a member when the member's leaf node in the MLS ratchet tree is updated, either by that member sending a Commit message, or by an Update proposal from that member being committed. Unfortunately, Update proposals can only be committed in the epoch in which they are sent, for example, if an Update proposal is sent Barnes, et al. Expires 9 January 2025 [Page 2] Internet-Draft MLS Replace July 2024 within an epoch, but not received by the sender of the Commit that ends the epoch until after the Commit is sent. This situation leads to missed opportunities for PCS. Unlike Add and Remove proposals, which can be "re-originated" by a committer if they are received late, Update proposals can only be sent by the member whose leaf the Update would replace. If an Update proposal is not included in the Commit ending its epoch, then it can only be discarded. The PCS benefits of the Update are lost. In this document, we define a Replace proposal that fills this gap. Where the Update proposal specifies only the new leaf node, a Replace specifies both the leaf node and the leaf index where the leaf node should be inserted. This allows any member of the group to take a leaf node value that another member has previously produced (e.g., in an Update proposal), and propose that the latter member's representation in the group be replaced with the new leaf node value. The new flexibility that this mechanism introduces can be abused by a malicious member to undermine PCS. The malicious member can issue a Replace proposal that rolls back a victim member's leaf to an earlier, compromised version. To prevent these attacks, we also introduce a leaf_node_epoch extension that allows a LeafNode to be annotated with the epoch in which it was created. This allows the recipients of a Replace proposal to ensure that the new leaf node was created after the one it replaces. 2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. This document makes use of the terms defined in [RFC9420]. 3. Leaf Node Epoch Extension The leaf_node_epoch extension simply describes the epoch in which a LeafNode was created: uint64 leaf_node_epoch; Figure 1: Content of the `leaf_node_epoch` extension Barnes, et al. Expires 9 January 2025 [Page 3] Internet-Draft MLS Replace July 2024 4. Replace Proposal A Replace proposal replaces the indicated LeafNode in the tree with the value provided in the proposal. struct { uint32 replaced; LeafNode leaf_node; } Replace; Figure 2: Content of the Replace proposal A Replace proposal is invalid if the LeafNode is invalid for an Update proposal for the indicated leaf according to Section 7.3 of [RFC9420], or if the leaf node at index removed is blank. In addition, the recipient of a Replace proposal MUST verify the following properties of the new LeafNode and reject the proposal as invalid if any one of them is false: * The leaf_node_source field of the LeafNode is be set to update. * The extensions field of the LeafNode contains an extension of type leaf_node_epoch. * The epoch value in the leaf_node_epoch field is less than or equal to the current epoch. * If the current LeafNode contains a leaf_node_epoch extension, then the epoch value in the leaf_node_epoch field is greater than or equal to the value in the current LeafNode. A member of the group applies a Replace proposal by taking the following steps: * Replace the LeafNode at index removed with the one contained in the Replace proposal. * Blank the intermediate nodes along the path from the leaf at index removed to the root. This mechanism is similar to the Update proposal described in Section 12.1.2 of [RFC9420], with the difference that the index of the leaf to be replaced is made explicit, as opposed to being indicated by the sender field of the enclosing FramedContent object. A Replace proposal with the to_replace field set to the same index as the sender field has the same effect as an Update sending the same leaf node value. Barnes, et al. Expires 9 January 2025 [Page 4] Internet-Draft MLS Replace July 2024 A Commit that contains a Replace proposal MUST contain an update path. 5. Proposal List Validation This specification extends the validation rules in Section 12.2 of [RFC9420] with the following additional rules governing proposal lists that include Replace proposals. For a regular, i.e., not external, Commit, the list is invalid if any of the following occurs (in addition to the rules in Section 12.2 of [RFC9420]): * It contains a Replace proposal replacing the committer's leaf node. * It contains multiple Replace proposals for the same leaf node. * It contains both a Replace proposal and an Update or Remove proposal for the same leaf node. Replace proposals are not allowed in external Commits. 6. Security Considerations As noted above, the Replace proposal introduces a risk that a malicioius group member could roll back a victim group member to an earlier, compromised LeafNode. Thus while the Replace and leaf_node_epoch mechanisms are notionally separate, using Replace proposals requires the use of the leaf_node_epoch extension in order to avoid roll-back attacks. In a group where Replace proposals might be used, the application SHOULD ensure that all leaf nodes contain a leaf_node_epoch extension. *TODO:* It might be worth defining a flag that says leaf_node_epoch is required. That would be a good use of an MLS flags extension, along the lines of [I-D.ietf-tls-tlsflags] (real reference not working right now), which would be a nice thing to include in the MLS extensions document. *TODO:* Unlike an Update proposal, a Replace proposal is not signed by the current (i.e. prior to update) key of the replaced member. This allows a malicious insider Bob to issue a Replace proposal for Alice that changes her signature key to one chosen by Bob (assuming Bob can obtain a valid credential for that key). This is not possible with Update proposals. It may be good to prevent this scenario e.g. by having a leaf node extension signature_under_previous_key required for Replace proposals that change the signature key. Barnes, et al. Expires 9 January 2025 [Page 5] Internet-Draft MLS Replace July 2024 7. IANA Considerations *TODO:* Register new proposal type Replace *TODO:* Register new extension type leaf_node_epoch 8. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [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, . Acknowledgments TODO acknowledge. Authors' Addresses Richard Barnes Cisco Email: rlb@ipv.sx Marta Mularczyk Amazon Email: mulmarta@amazon.com Mark Xue Germ Network, Inc. Email: mark@germ.network Barnes, et al. Expires 9 January 2025 [Page 6]