The MLS Replace Proposal
draft-barnes-mls-replace-00
| Document | Type |
Expired Internet-Draft
(individual)
Expired & archived
|
|
|---|---|---|---|
| Authors | Richard Barnes , Marta Mularczyk , Mark Xue | ||
| Last updated | 2025-01-09 (Latest revision 2024-07-08) | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Expired | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
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.
Authors
Richard Barnes
Marta Mularczyk
Mark Xue
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)