| Internet-Draft | MLS Replace | July 2024 |
| Barnes, et al. | Expires 9 January 2025 | [Page] |
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.¶
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:[email protected]), 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.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
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 (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.¶
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 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.¶
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.¶
The leaf_node_epoch extension simply describes the epoch in which a LeafNode
was created:¶
uint64 leaf_node_epoch;
A Replace proposal replaces the indicated LeafNode in the tree with the value provided in the proposal.¶
struct {
uint32 replaced;
LeafNode leaf_node;
} Replace;
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.¶
A Commit that contains a Replace proposal MUST contain an update path.¶
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.¶
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.¶
TODO: Register new proposal type Replace¶
TODO: Register new extension type leaf_node_epoch¶
TODO acknowledge.¶