Including Pending Proposals in External Commits in the Messaging Layer Security protocol
draft-mahy-mls-ext-commit-pp-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Rohan Mahy | ||
| Last updated | 2026-03-02 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-mahy-mls-ext-commit-pp-01
Messaging Layer Security R. Mahy
Internet-Draft 2 March 2026
Intended status: Informational
Expires: 3 September 2026
Including Pending Proposals in External Commits in the Messaging Layer
Security protocol
draft-mahy-mls-ext-commit-pp-01
Abstract
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
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at
https://rohanmahy.github.io/mls-ext-commit-pp/draft-mahy-mls-ext-
commit-pp.html. Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-mahy-mls-ext-commit-pp/.
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/rohanmahy/mls-ext-commit-pp.
Status of This Memo
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/.
Mahy Expires 3 September 2026 [Page 1]
Internet-Draft MLS Pending Proposals in External Commit March 2026
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 3 September 2026.
Copyright Notice
Copyright (c) 2026 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. Problem Use Cases . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Leaving a group . . . . . . . . . . . . . . . . . . . . . 3
3.2. External policy enforcer . . . . . . . . . . . . . . . . 4
4. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 5
5.1. Authentication of Proposals by Potential Joiner . . . . . 5
5.2. Authentication of Proposals by a policy enforcing DS . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
MLS [RFC9420] 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.
Mahy Expires 3 September 2026 [Page 2]
Internet-Draft MLS Pending Proposals in External Commit March 2026
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.
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 relies on many terms and struct names from [RFC9420].
3. Problem Use Cases
3.1. 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
Section 6.4 of [I-D.ietf-mls-extensions]) 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.
Mahy Expires 3 September 2026 [Page 3]
Internet-Draft MLS Pending Proposals in External Commit March 2026
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 ([I-D.ietf-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.
3.2. 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
[I-D.ietf-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.
Mahy Expires 3 September 2026 [Page 4]
Internet-Draft MLS Pending Proposals in External Commit March 2026
4. 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:
struct {
} ExternalPendingProposalsContents;
The provider of the GroupInfo is expected to provide all the pending
proposals it has received at the point it provides the GroupInfo.
5. Security Considerations
5.1. 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.
[I-D.kohbrok-mls-leaf-operation-intents] describes a mechanism by
which leavers can prove their intent to leave and, at the time, their
membership in an MLS group.
5.2. 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 [RFC9420] 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.
6. IANA Considerations
This document requests the addition of a new MLS Extension Type under
the heading of "Messaging Layer Security".
Mahy Expires 3 September 2026 [Page 5]
Internet-Draft MLS Pending Proposals in External Commit March 2026
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
7. References
7.1. Normative References
[I-D.ietf-mls-extensions]
Robert, R., "The Messaging Layer Security (MLS)
Extensions", Work in Progress, Internet-Draft, draft-ietf-
mls-extensions-08, 21 July 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-mls-
extensions-08>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[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, <https://www.rfc-editor.org/rfc/rfc9420>.
7.2. Informative References
[I-D.ietf-mimi-protocol]
Barnes, R., Hodgson, M., Kohbrok, K., Mahy, R., Ralston,
T., and R. Robert, "More Instant Messaging
Mahy Expires 3 September 2026 [Page 6]
Internet-Draft MLS Pending Proposals in External Commit March 2026
Interoperability (MIMI) using HTTPS and MLS", Work in
Progress, Internet-Draft, draft-ietf-mimi-protocol-05, 20
October 2025, <https://datatracker.ietf.org/doc/html/
draft-ietf-mimi-protocol-05>.
[I-D.ietf-mimi-room-policy]
Mahy, R., "Room Policy for the More Instant Messaging
Interoperability (MIMI) Protocol", Work in Progress,
Internet-Draft, draft-ietf-mimi-room-policy-03, 18
December 2025, <https://datatracker.ietf.org/doc/html/
draft-ietf-mimi-room-policy-03>.
[I-D.kohbrok-mls-leaf-operation-intents]
Kohbrok, K., "Leaf Operation Intents", Work in Progress,
Internet-Draft, draft-kohbrok-mls-leaf-operation-intents-
01, 20 October 2025,
<https://datatracker.ietf.org/doc/html/draft-kohbrok-mls-
leaf-operation-intents-01>.
Author's Address
Rohan Mahy
Email: rohan.ietf@gmail.com
Mahy Expires 3 September 2026 [Page 7]