Messaging Layer Security K. Kohbrok Internet-Draft R. Robert Intended status: Informational Phoenix R&D Expires: 7 August 2026 3 February 2026 A two-party profile for MLS draft-kohbrok-mls-two-party-profile-00 Abstract TODO Abstract 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://kkohbrok.github.io/draft-kohbrok-mls-two-party-profile/draft- kohbrok-mls-two-party-profile.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft- kohbrok-mls-two-party-profile/. 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/kkohbrok/draft-kohbrok-mls-two-party-profile. 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/. 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 7 August 2026. Kohbrok & Robert Expires 7 August 2026 [Page 1] Internet-Draft 2PMLS February 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. Protocol overview . . . . . . . . . . . . . . . . . . . . . . 3 3. Initial key agreement . . . . . . . . . . . . . . . . . . . . 3 4. Continuous key agreement . . . . . . . . . . . . . . . . . . 4 5. Resumption . . . . . . . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 5 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction MLS is primarily designed to be a continuous group key agreement (and messaging) protocol. This document explores the special case of groups of two and thus MLS's use as a (non-group) continuous key agreement protocol with a focus on the use in synchronous scenarios. The two-party profile of MLS described in this document can, for example, be used as a replacement for other key exchange protocols that don't provide post-compromise security and/or post-quantum security. This is the case with the key exchange components for many secure channel protocols today. TODO: For now, this document specifies a simple two party profile based on vanilla MLS that assumes synchronous communication. In the future, we should explore the asynchronous case and add a more specialized version that trims unnecessary things like signatures in key update messages, etc. Kohbrok & Robert Expires 7 August 2026 [Page 2] Internet-Draft 2PMLS February 2026 2. Protocol overview The synchronous case assumes that both parties are online. The party sending the first message is the initiator and the other party the responder. The protocol can be split into three phases. 1. Initial key agreement 2. Continuous key agreement 3. Resumption In Phase 1, the initiator and responder exchange messages until they agree on a shared key and thus enter Phase 2. In Phase 2, both parties can perform key-updates to achieve forward- secrecy (FS) and post-compromise security (PCS). To avoid de- synchronization, both parties have to await confirmation of each update by the other party before they can perform another one. This phase continues until the connection between the parties is interrupted. Phase 3 allows either party to resume the connection. During resumption, initiator and responder exchange messages to renew their key material before they (re-)enter Phase 2. While the synchronous two-party case is significantly simpler when it comes to the responsibilities of the MLS Delivery Service, it still requires both parties to interface with an Authentication Service to validate both initial credentials and any credential updates. 3. Initial key agreement struct { MLSMessage key_package; } ClientHello struct { MLSMessage welcome; } ServerHello The initiator starts the key agreement part of the protocol by creating a KeyPackage and sending a ClientHello to the responder. The responder inspects the KeyPackage and checks whether it supports the offered ciphersuite and whether the initiator has sufficient capabilities to support the connection. Kohbrok & Robert Expires 7 August 2026 [Page 3] Internet-Draft 2PMLS February 2026 The responder MUST interface with the AS to ensure that the credential in the KeyPackage is valid. The responder then locally creates an MLS group and commits to an Add proposal containing the initiator's KeyPackage. The responder sends the resulting Welcome message back to the initiator as part of a ServerHello message. The initiator uses the Welcome to create its local group state. The initiator then inspects the group state and MUST interface with the AS to ensure that the credential of the responder is valid. 4. Continuous key agreement struct { MLSMessage update } ConnectionUpdate struct { uint64 epoch; } EpochKeyUpdate After the initial key agreement phase, both parties can send an MLS commit with UpdatePath to update their key material. To ensure that both agree on the order of such commits and thus on the currently used key material, they must follow the following rules. * Each party may send a ConnectionUpdate if they are not currently waiting for an EpochKeyUpdate to confirm a previous ConnectionUpdate * If either party receives a ConnectionUpdate and they're not currently waiting for an EpochKeyUpdate, they MUST validate and apply the commit and respond with an EpochKeyUpdate, where epoch is the group's new epoch * If the initiator receives a ConnectionUpdate while waiting for an EpochKeyUpdate, it MUST ignore the ConnectionUpdate and resume waiting * If the responder receives a ConnectionUpdate while waiting for an EpochKeyUpdate, it MUST drop its locally pending commit and validate and apply the commit as if it hadn't been waiting for an EpochKeyUpdate * A party receiving a ConnectionUpdate MUST start using the key material of the new epoch after sending the EpochKeyUpdate Kohbrok & Robert Expires 7 August 2026 [Page 4] Internet-Draft 2PMLS February 2026 * A party sending a ConnectionUpdate MUST wait until they receive the corresponding EpochKeyUpdate before they start using the key material of the new epoch 5. Resumption Either party may resume a previously interrupted protocol session based on that session's group state. The party initiating the resumption becomes the initiator. struct { MLSMessage commit; } ResumptionRequest struct { MLSMessage commit; } ResumptionResponse The initiator sends a Resumption message to the responder. If the initiator was waiting for an EpochKeyUpdate while the connection was interrupted, it MUST include the commit from the last ConnectionUpdate in the Resumption message. The initiator MUST then wait for a ResumptionResponse. The responder receiving a ResumptionRequest MUST validate and apply the commit in the ResumptionRequest and create a commit with UpdatPath to send back as part of a ResumptionResponse. If one of the parties receives a ResumptionRequest while waiting for a ResumptionResponse, their reaction depends whether they were the initial initiator or responder when the connection was first established. The initial initiator MUST drop the ResumptionRequest and continue waiting. The initial responder MUST drop its pending commit and instead validate and apply the incoming commit before responding with a fresh commit as part of a ResumptionResponse. 6. Security Considerations TODO Security 7. IANA Considerations This document has no IANA actions. Acknowledgments TODO acknowledge. Kohbrok & Robert Expires 7 August 2026 [Page 5] Internet-Draft 2PMLS February 2026 Contributors Russ Housley Vigil Security Email: housley@vigilsec.com Authors' Addresses Konrad Kohbrok Phoenix R&D Email: konrad@ratchet.ing Raphael Robert Phoenix R&D Email: ietf@raphaelrobert.com Kohbrok & Robert Expires 7 August 2026 [Page 6]