Messaging Layer Security R. Robert Internet-Draft K. Kohbrok Intended status: Informational Phoenix R&D Expires: 3 September 2026 2 March 2026 Fewer signatures in MLS draft-kohbrok-mls-fewer-signatures-00 Abstract This draft specifies modified versions of MLS KeyPackage messages, as well as MLS PublicMessages and PrivateMessages holding Commits or Update Proposals that require one less signature than their original counterparts. 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-fewer-signatures.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-kohbrok-mls-fewer-signatures/. 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/. Robert & Kohbrok Expires 3 September 2026 [Page 1] Internet-Draft FSMLS 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 2. New MLSMessage variants . . . . . . . . . . . . . . . . . . . 3 3. One Signature KeyPackages . . . . . . . . . . . . . . . . . . 4 3.1. Creating a OneSignatureKeyPackage . . . . . . . . . . . . 4 3.2. OuterKeyPackage hash component . . . . . . . . . . . . . 4 3.3. Processing a OneSignatureKeyPackage . . . . . . . . . . . 5 4. One Signature Commits and Update Proposals . . . . . . . . . 5 4.1. Changes in framing . . . . . . . . . . . . . . . . . . . 5 4.2. Changes in membership tag and transcript hash computation . . . . . . . . . . . . . . . . . . . . . . . 7 4.3. Outer update hash component . . . . . . . . . . . . . . . 7 4.4. Creating an OSPublicMessage or OSPrivateMessage . . . . . 9 4.5. Processing an OSPublicMessage or OSPrivateMessage . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6.1. Component Types . . . . . . . . . . . . . . . . . . . . . 10 6.1.1. OuterKeyPackageHash . . . . . . . . . . . . . . . . . 10 6.1.2. OuterUpdateHash . . . . . . . . . . . . . . . . . . . 10 6.2. WireFormat . . . . . . . . . . . . . . . . . . . . . . . 11 6.2.1. MLSOneSignatureKeyPackage . . . . . . . . . . . . . . 11 6.2.2. MLSOneSignaturePrivateMessage . . . . . . . . . . . . 11 6.2.3. MLSOneSignaturePublicMessage . . . . . . . . . . . . 11 7. Normative References . . . . . . . . . . . . . . . . . . . . 12 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Robert & Kohbrok Expires 3 September 2026 [Page 2] Internet-Draft FSMLS March 2026 1. Introduction Both MLS KeyPackage messages, as well as PublicMessages and PrivateMessages holding Commits and Update Proposals can be safely sent with one fewer signature than specified in [RFC9420], although the latter two only if certain conditions are met. Regular MLS KeyPackages require two signatures: One over the LeafNode and one over the KeyPackage around it. This draft introduces a LeafNode component that contains a hash over the KeyPackage fields surrounding the LeafNode. As a consequence, verifying the LeafNode also verifies the KeyPackage. For Commits with an UpdatePath or Update Proposals (sent as PublicMessage or PrivateMessage) the issue is similar: One signature covers the LeafNode and one signature covers the majority of the struct that ends up being sent over the wire. This draft proposes new types of PublicMessage and PrivateMessage with only one signature, although the signature can only be omitted for Commits that contain an UpdatePath and for Commits and Update Proposals if the LeafNode doesn't change the sender's signature public key. Saving a signature can result in a significant decrease in computational or bandwidth cost, 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. New MLSMessage variants This document specifies three new entries for the IANA WireFormat registry, which results in the following changes to the MLSMessage struct as defined in [RFC9420]. struct { ... select (MLSMessage.wire_format) { ... case mls_os_key_package: OneSignatureKeyPackage key_package; case mls_os_private_message: OSPrivateMessage private_message; case mls_os_public_message: OSPublicMessage public_message; }; } MLSMessage; Robert & Kohbrok Expires 3 September 2026 [Page 3] Internet-Draft FSMLS March 2026 See Section 3 for the definition of OneSignatureKeyPackage and Section 4 for the definitions of OSPrivateMessage and OSPublicMessage. 3. One Signature KeyPackages A OneSignatureKeyPackage functions like a regular KeyPackage, except that it's partitioned into two components: The OuterKeyPackage and the LeafNode. The OuterKeyPackage contains all fields of a regular KeyPackage except the LeafNode and the signature. struct { ProtocolVersion version; CipherSuite cipher_suite; HPKEPublicKey init_key; Extension extensions; } OuterKeyPackage struct { OuterKeyPackage outer_key_package; LeafNode leaf_node; } OneSignatureKeyPackage 3.1. Creating a OneSignatureKeyPackage A OneSignatureKeyPackage is created like a regular KeyPackage with the following exceptions. * The signature around the outer KeyPackage is omitted * An app_data_dictionary extension is added to the LeafNode (if not already present) * An OuterKeyPackageHash component is included in the app_data_dictionary (see Section 3.2) The original purpose of the signature over the KeyPackage is now served by the signature over the LeafNode, which by inclusion of the OuterKeyPackageHash provides authenticity for both the LeafNode itself _and_ the OuterKeyPackage around it. 3.2. OuterKeyPackage hash component struct { opaque outer_key_package_hash; } OuterKeyPackageHash Robert & Kohbrok Expires 3 September 2026 [Page 4] Internet-Draft FSMLS March 2026 The OuterKeyPackageHash can be created by hashing the TLS-serialized outer_key_package of a OneSignatureKeyPackage using the hash function of its ciphersuite. A OuterKeyPackageHash 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 OneSignatureKeyPackage, the outer_key_package_hash is the hash of the outer_key_package of that OneSignatureKeyPackage. 3.3. Processing a OneSignatureKeyPackage Recipients of a OneSignatureKeyPackage process is like a regular KeyPackage with two exceptions * There is no signature over the outer KeyPackage to verify * The app_data_dictionary extension in the leaf_node must contain a valid OuterKeyPackageHash as defined in Section 3.2 under the component_id TBD. 4. One Signature Commits and Update Proposals MLS PublicMessages and PrivateMessages carrying a Commit with UpdatePath or an Update Proposal can also be created with only one signature as long as the signature key of the sender is not changed by the respective operation. The resulting structs are called OSPublicMessage and OSPrivateMessage respectively. The principle behind saving the signature is the same as for OneSignatureKeyPackage. The signature over the whole struct is omitted and instead a hash over the otherwise signed part of the struct (minus the LeafNode) is placed as a component in the LeafNode of the UpdatePath or the Update Proposal. 4.1. Changes in framing The core change in framing an OSPublicMessage or OSPrivateMessage as compared to its regular counterparts is that the FramedContentAuthData is replaced by the OSFramedContentAuthData, where the latter lacks the signature that is part of the former. Other framing structs are changed as a result in that they contain an OSFramedContentAuthData struct instead of a FramedContentAuthData struct. Robert & Kohbrok Expires 3 September 2026 [Page 5] Internet-Draft FSMLS March 2026 struct { select (FramedContent.content_type) { case commit: /* MAC(confirmation_key, GroupContext.confirmed_transcript_hash) */ MAC confirmation_tag; case application: case proposal: struct{}; }; } OSFramedContentAuthData; struct { WireFormat wire_format; FramedContent content; OSFramedContentAuthData auth; } OSAuthenticatedContent; struct { select (PrivateMessage.content_type) { case application: opaque application_data; case proposal: Proposal proposal; case commit: Commit commit; }; OSFramedContentAuthData auth; opaque padding[length_of_padding]; } OSPrivateMessageContent; struct { FramedContent content; OSFramedContentAuthData auth; select (PublicMessage.content.sender.sender_type) { case member: MAC membership_tag; case external: case new_member_commit: case new_member_proposal: struct{}; }; } OSPublicMessage; Robert & Kohbrok Expires 3 September 2026 [Page 6] Internet-Draft FSMLS March 2026 4.2. Changes in membership tag and transcript hash computation The structs involved in membership tag and transcript hash computation also change slightly. struct { FramedContentTBS content_tbs; OSFramedContentAuthData auth; } OSAuthenticatedContentTBM; For OSPublicMessages, the membership_tag is computed over OSAuthenticatedContentTBM instead of the regular AuthenticatedContentTBM. struct { WireFormat wire_format; FramedContent content; /* with content_type == commit */ } OSConfirmedTranscriptHashInput; Due to the changes in framing, the transcript hash for OSPublicMessages and OSPrivateMessages is computed over OSConfirmedTranscriptHashInput instead of the regular ConfirmedTranscriptHash. Since the LeafNode is within FramedContent and its signature covers what the original signature would have covered, this does not affect transcript coverage. 4.3. Outer update hash component The OuterUpdateHash component ensures that the signature over the LeafNode covers whatever the omitted signature would have covered. Robert & Kohbrok Expires 3 September 2026 [Page 7] Internet-Draft FSMLS March 2026 struct { opaque outer_update_hash; } OuterUpdateHash struct { opaque group_id; uint64 epoch; Sender sender; opaque authenticated_data; ContentType content_type; select (FramedContent.content_type) { case proposal: ProposalType proposal_type; case commit: ProposalOrRef proposals; UpdatePathNode nodes; case application: struct {}; }; } OuterFramedContent struct { ProtocolVersion version = mls10; WireFormat wire_format; OuterFramedContent content; GroupContext context; } OSFramedContentTBH The outer_update_hash MUST be a hash over the message's TLS- serialized OSFramedContentTBH using the hash function of the group's ciphersuite. OSFramedContentTBH is the same as the FramedContentTBS struct defined in [RFC9420], except that it always contains a GroupContext (because Commits and Update Proposals only have member or new_member_commit as sender_type) and that it contains an OuterFramedContent instead of a regular FramedContent. OuterFramedContent in turn is the same as FramedContent except that, depending on content_type, it either contains only content relevant to a Commit with an UpdatePath or an Update Proposal. For Commits, the proposals MUST be the same as in the message's Commit and the nodes MUST be equal to the nodes in the Commit's UpdatePath. For Update Proposals, the proposal_type MUST be update. The proposal type is the only relevant content, as the Update Proposal otherwise only consists of the (omitted) LeafNode. Robert & Kohbrok Expires 3 September 2026 [Page 8] Internet-Draft FSMLS March 2026 In both cases, the actual LeafNode is omitted to prevent a circular dependency when computing the outer_update_hash for inclusion in said LeafNode. 4.4. Creating an OSPublicMessage or OSPrivateMessage Clients create an OSPublicMessage or OSPrivateMessage just like their non-OS counterpart with three exceptions: * The signature in FramedContentData is omitted by using OSFramedContentData and the other modified structs introduced in Section 4.1 instead of their non-OS counterparts. * An app_data_dictionary is included in the LeafNode (either in the UpdatePath or the Update Proposal) and within it an OuterUpdateHash component (see Section 4.3). * The membership tag and transcript hash are computed as specified in Section 4.2. 4.5. Processing an OSPublicMessage or OSPrivateMessage OSPublicMessages and OSPrivateMessages are processed like their regular counterparts with the following exceptions. * One of the following MUST be true - content_type = commit and the Commit contained within MUST have an UpdatePath - content_type = proposal and proposal_type = update * The signature public key in the LeafNode MUST be the same as the sender's current LeafNode. This MUST also be true for Commits with sender_type = new_member_commit that contain a Remove Proposal targeting the sender's original leaf. * The LeafNode (either in the UpdatePath or in the Update Proposal) MUST contain an app_data_dictionary extension with a valid OuterUpdateHash component as specified in Section 4.3. * Membership tag and transcript hash are computed as specified in Section 4.2. Robert & Kohbrok Expires 3 September 2026 [Page 9] Internet-Draft FSMLS March 2026 The second check for signature public key equality is necessary to ensure that the authentication properties of one-signature message variants are equivalent to their counterparts defined in RFC9420. Clients that want to change their signature public key MUST use the normal (external) Commits and Update Proposals to ensure that the new signature public key is signed by the old one. 5. Security Considerations Security considerations around the one signature variants are the same as those of their regular MLS counterparts, except their content should not be trusted until the signature of the LeafNode was verified and the OuterKeyPackageHash or OuterUpdateHash component was validated. 6. IANA Considerations 6.1. Component Types This document requests the addition of two new Component Types under the heading of "Messaging Layer Security". 6.1.1. OuterKeyPackageHash The OuterKeyPackageHash component contains a hash over the outer parts of a OneSignatureKeyPackage. * Value: TBD (suggested value 0x0009) * outer_key_package_hash * Where: LN * Recommended: Y * Reference: TBD 6.1.2. OuterUpdateHash The OuterUpdateHash component contains a hash over the parts of an OSPublicMessage or OSPrivateMessage that would otherwise be covered by a signature. * Value: TBD (suggested value 0x000C) * outer_update_hash * Where: LN Robert & Kohbrok Expires 3 September 2026 [Page 10] Internet-Draft FSMLS March 2026 * Recommended: Y * Reference: TBD 6.2. WireFormat This document requests the addition of three new WireFormats under the heading of "Messaging Layer Security". 6.2.1. MLSOneSignatureKeyPackage The mls_os_key_package allows saving the creation and verification of a signature that is necessary when creating a regular KeyPackage. * Value: TBD * Name: mls_os_key_package * Recommended: Y * Reference: TBD 6.2.2. MLSOneSignaturePrivateMessage The mls_os_private_message allows saving the creation and verification of a signature that is necessary when creating a regular PrivateMessage that either contains a Commit with an UpdatePath or an Update Proposal. * Value: TBD * Name: mls_os_private_message * Recommended: Y * Reference: TBD 6.2.3. MLSOneSignaturePublicMessage The mls_os_public_message allows saving the creation and verification of a signature that is necessary when creating a regular PublicMessage that either contains a Commit with an UpdatePath or an Update Proposal. * Value: TBD * Name: mls_os_public_message Robert & Kohbrok Expires 3 September 2026 [Page 11] Internet-Draft FSMLS March 2026 * Recommended: Y * Reference: TBD 7. 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 3 September 2026 [Page 12]