]> Phoenix R&D

ietf@raphaelrobert.com

Phoenix R&D

konrad@ratchet.ing

Security Messaging Layer Security mls Single Signature KeyPackages improve the overhead of creating, transmitting and verifying MLS KeyPackages by removing one signature. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Messaging Layer Security Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

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.

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. 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 as follows. ; } 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 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.

KeyPackage core hash component 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.

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.

IANA Considerations

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

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
• Recommended: Y
• Reference: TBD

Normative References Messaging applications are increasingly making use of end-to-end security mechanisms to ensure that messages are only accessible to the communicating endpoints, and not to any servers involved in delivering messages. Establishing keys to provide such protections is challenging for group chat settings, in which more than two clients need to agree on a key but may not be online at the same time. In this document, we specify a key establishment protocol that provides efficient asynchronous group key establishment with forward secrecy (FS) and post-compromise security (PCS) for groups in size ranging from two to thousands.

Acknowledgments TODO acknowledge.