Messaging Layer Security R. Robert Internet-Draft K. Kohbrok Intended status: Informational Phoenix R&D Expires: 23 April 2026 20 October 2025 Single Signature KeyPackages draft-kohbrok-mls-single-signature-keypackages-00 Abstract Single Signature KeyPackages improve the overhead of creating, transmitting and verifying MLS KeyPackages by removing one signature. 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-single-signature- keypackages/draft-kohbrok-mls-single-signature-keypackages.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-kohbrok-mls-single-signature- keypackages/. 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-single-signature- keypackages. 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." Robert & Kohbrok Expires 23 April 2026 [Page 1] Internet-Draft sskp October 2025 This Internet-Draft will expire on 23 April 2026. 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. Single Signature KeyPackages . . . . . . . . . . . . . . . . 2 3. KeyPackage core hash component . . . . . . . . . . . . . . . 3 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 5.1. Component Type . . . . . . . . . . . . . . . . . . . . . 4 5.2. WireFormat . . . . . . . . . . . . . . . . . . . . . . . 4 6. Normative References . . . . . . . . . . . . . . . . . . . . 5 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction MLS KeyPackages require two signatures: One over the LeafNode and one over the KeyPackage around it. This draft introduced a LeafNode component that contains a hash over the KeyPackage fields surrounding the LeafNode. As a consequenve, verifying the LeafNode also verifies the KeyPackage. Saving a signature is significant, especially in the context of PQ- secure signature schemes such as ML-DSA, where signatures are multiple orders of magnitude larger than those of most non-PQ signature schemes. 2. Single Signature KeyPackages A SingleSignatureKeyPackage (SSKP) functions much like a regular KeyPackage with two exceptions: It lacks the signature around the outer KeyPackage and requires a component inside the LeafNode that contains a hash of the KeyPackage around the inner LeafNode. Robert & Kohbrok Expires 23 April 2026 [Page 2] Internet-Draft sskp October 2025 Since both parsing and processing of an SSKP is different from that of a regular KeyPackage, this document introduces a new WireFormat mls_single_signature_key_package and extends the select statement in the definition of MLSMessage in Section 6 of [RFC9420] as follows. struct { ... select (MLSMessage.wire_format) { ... case mls_single_signature_key_package: SingleSignatureKeyPackage key_package; }; } MLSMessage; struct { ProtocolVersion version; CipherSuite cipher_suite; HPKEPublicKey init_key; Extension extensions; } KeyPackageCore struct { KeyPackageCore core; LeafNode leaf_node; } SingleSignatureKeyPackage A SingleSignatureKeyPackage is created and processed like a regular KeyPackage with the following exceptions. * The signature around the outer KeyPackage is omitted upon creation * As there is no signature around the outer KeyPackage, verification is skipped during verification * The app_data_dictionary in the leaf_node must contain a valid KeyPackageCoreHash as defined in Section 3 under the component_id TBD. The original purpose of the signature over the KeyPackage is now served by the signature over the LeafNode, which by inclusion of the KeyPackageCoreHash provides authenticity for both the LeafNode itself _and_ the KeyPackageCore around it. 3. KeyPackage core hash component struct { opaque key_package_core_hash; } KeyPackageCoreHash Robert & Kohbrok Expires 23 April 2026 [Page 3] Internet-Draft sskp October 2025 The KeyPackageCoreHashComponent can be created by hashing the TLS- serialized core of a SingleSignatureKeyPackage using the hash function of the LeafNode's ciphersuite. A KeyPackageCoreHash is only valid if two conditions are met. * The leaf_node_source of the LeafNode is KeyPackage * If the LeafNode is verified in the context of a SingleSignatureKeyPackage, the key_package_core_hash is the hash of the core of that SingleSignatureKeyPackage. 4. Security Considerations Security considerations around SingleSignatureKeyPackages are the same as regular KeyPackages, except that content of the KeyPackageCore should not be trusted until the signature of the LeafNode was verified and the KeyPackageCoreHash validated. 5. IANA Considerations 5.1. Component Type This document requests the addition of a new Component Type under the heading of "Messaging Layer Security". * Value: TBD * key_package_core_hash * Where: LN * Recommended: Y * Reference: TBD 5.2. WireFormat This document requests the addition of a new WireFormat under the heading of "Messaging Layer Security". The mls_single_signature_key_package allows saving the creation and verification of a signature that is necessary when creating a regular KeyPackage. * Value: TBD * Name: mls_single_signature_key_package Robert & Kohbrok Expires 23 April 2026 [Page 4] Internet-Draft sskp October 2025 * Recommended: Y * Reference: TBD 6. Normative References [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, . Acknowledgments TODO acknowledge. Authors' Addresses Raphael Robert Phoenix R&D Email: ietf@raphaelrobert.com Konrad Kohbrok Phoenix R&D Email: konrad@ratchet.ing Robert & Kohbrok Expires 23 April 2026 [Page 5]