Messaging Layer Security K. Kohbrok Internet-Draft Phoenix R&D Intended status: Informational 17 March 2025 Expires: 18 September 2025 Decentralized Messaging Layer Security draft-kohbrok-mls-dmls-00 Abstract Messaging Layer Security provides strong end-to-end security guarantees for group messaging including Forward Secrecy (FS) and Post-Compromise Security (PCS). However, MLS requires a Delivery Service (DS) to facilitate agreement between group members on the order of Commit messages. In decentralized settings the only way to implement a functional DS is to require group members to retain key material so they can process commits out-of-order. Retaining key material this way is in violation of the MLS deletion schedule and significantly reduces the FS of the protocol. This draft specifies Decentralized MLS, based on the the Fork-Resilient Continuous Group Key Agreement protocol FREEK proposed by Alwen et al. [FRCGKA]. In essence, DMLS extends MLS such that key material can be retained to process Commits out-of-order with minimal losses to FS, thus allowing safer deployment in decentralized environments. 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://phnx- im.github.io/dmls-spec/draft-kohbrok-mls-dmls.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-kohbrok-mls-dmls/. Discussion of this document takes place on the Messaging Layer Security 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/phnx-im/dmls-spec. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Kohbrok Expires 18 September 2025 [Page 1] Internet-Draft DMLS March 2025 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 18 September 2025. Copyright Notice Copyright (c) 2025 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. Epoch identifiers . . . . . . . . . . . . . . . . . . . . . . 3 3. DMLS key schedule . . . . . . . . . . . . . . . . . . . . . . 3 4. Puncturable pseudorandom function . . . . . . . . . . . . . . 4 5. State consolidation . . . . . . . . . . . . . . . . . . . . . 5 5.1. Consolidation algorithm . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . 7 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction TODO: Introduction Kohbrok Expires 18 September 2025 [Page 2] Internet-Draft DMLS March 2025 Open Questions: - Why do removed members need to receive their commit confirmation from their removers? They should be able to process the removing commit without the init secret in the first place. - Is it safe to use the commit secret regularly in the key schedule _and_ to derive the commit confirmation or do we need an additional derivation step to ensure domain separation? - Why would we need to generate a fresh signature key pair with each update? - Do we need an additional membership tag? 2. Epoch identifiers In MLS, each epoch is identified by a 64 bit unsigned integer, with the epoch increasing by one with each commit. The integer identifies epochs uniquely as long as there is only one chain of Commits. However, in a decentralized context there can be conflicting commits. For example, if two group member send a commit at the same time with different subsets of group members receiving a different commit first. After processing the newly arrived Commit, all group members would be in the same epoch, but in different group states. For subsequently arriving messages, it is unclear from the integer designating the epoch, which state the message belongs to. In such scenarios it is important that epochs are uniquely identifiable. When using DMLS, epochs are represented as byte strings of length KDF.Nh (thus depending on the group's ciphersuite). The byte string identifying an epoch is derived from the epoch's epoch_secret and can thus be learned when creating or processing the commit that initiates that epoch. pseudocode epoch = DeriveSecret(epoch_secret, "epoch") 3. DMLS key schedule DMLS conceptually modifies the MLS key schedule by enabling the creation of multiple init_secrets, where each init secret can be used to initialize a subsequent epoch. The individual init_secrets are derived through a puncturable pseudorandom function (PPRF, Section 4) keyed by the base_init_secret. Kohbrok Expires 18 September 2025 [Page 3] Internet-Draft DMLS March 2025 (above the same as the MLS key schedule) | V epoch_secret | | +--> DeriveSecret(.,