]> Rohan Mahy Consulting Services

rohan.ietf@gmail.com

membership proof safe extension This document describes an MLS safe extension that members of a group can use to assert membership to non-members. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction The Messaging Layer Security (MLS) Protocol is a group key management protocol which also provides group agreement on the membership and group context during each epoch. This document defines a Safe Extension (Section 2 of ) that can be used for members to assert membership in the group to non-members (for example, an MLS Distribution Service), such that a dishonest assertion will be immediately apparent to other members. This extension includes a new epoch-derived secret called the member_proof; a description of how to export the member_proof public key; a description of how to include in the Additional Authentication Data (AAD) of MLS encrypted messages, and a signature of a usage-specfic struct of an encrypted message signed with the member_proof private key. Depending on the specific usage of this extension, signing specific MLS messages could be either required for every member of a group, or used optionally by any member as it sees fit. The document also defines a usage for sharing signatures of handshake messages so they can be safely shared out-of-band with another party (for example an MLS Distribution Service).

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. This document refers to TLS Presentation Language structs defined in the MLS protocol .

Mechanism

Sending a PrivateMessage with a membership proof This document defines a new Safe Extension for sending a membership proof in the Additional Authenticated Data (AAD) of an MLS PrivateMessage. A sender follows the following steps:

1. Derive the member_proof key pair using the ExtensionType member_proof. The private key is known as MemberProofPrivKey and the public key is known as MemberProofPubKey.
2. Generate a new unique nonce of KDF.Nh octets using the Key Derivation Function of the current cipher suite.
3. Calculate the hash of the concatenation of the nonce and whatever data (the UsageData) is required by the usage of the application. The hash function is the hash function from the current cipher suite. The hash is known as the (ContentHash)

1. Sign ContentHash with the ExtensionType for the usage, using the member_proof private key (MemberProofPrivKey):

where ExtensionType is the IANA-assigned value for the usage, MemberProofPrivKey is the private key derived from member_proof for the current epoch, and ContentHash is calculated in the previous step. (Label is defined as "MLS 1.0 ExtensionData" in .)

1. The MemberProofAAD struct is conveyed in the aad_item_data of the aad_items of the authenticated_data of the PrivateMessage, using the usage's ExtensionType.

tls struct { opaque nonce<V>; opaque safe_signature<V>; optional opaque MemberProofPubKey; } MemberProofAAD; The MemberProofPubKey public key SHOULD be included unless the sender knows the intended target will receive it another way.

Verifying a PrivateMessage with a membership proof

1. Verify that the AAD in messages conforms to the policy of the group (that required items are present, and forbidden )
2. If present, find the MemberProofAAD in the aad_items of the authenticated_data of a PrivateMessage; extract the nonce, safe_signature and MemberProofPubKey.
3. Members verify that the MemberProofPubKey matches the derived key for member_proof for the current epoch.
4. Members calculate the ContentHash of the nonce and the relevant UsageData.
5. Members verify that the safe_signature is correct.
6. Perform any additional usage-related verifications.

Handshake Sharing Usage This document also defines a usage of this member proofs to share an unencrypted copy of the FramedContent of commits and proposals (collectively handshake messages) that are inside an MLS PrivateMessage, typically to an MLS Distribution Service (DS). It creates the handshake_framed_data_hash extension_type. For this usage the UsageData consists of the FramedContent of the handshake message. The client sending the handshake message makes an assurance that the handshake message is the same as the encrypted one. The sharing client can share a copy of the FramedContent of the handshakes with the DS. The DS calculates the signature on FramedContent it receives with the signature in the MemberProofAAD of the PrivateMessage. Other members compare the signature in the MemberProofAAD with their own in-group copy of the FramedContent. If the signature does not match, the other members know that the the sharing client is either malicious or has a bug. In either case, the other clients know that they can no longer trust the sharing client and can take whatever actions are necessary to exclude it (ex: informing the DS, forcibly removing the client from the group if possible, or creating new groups without the client). When a client sends commit message using this usage, it can also send a SafeAADItem with the extension_type of next_epoch_member_proof_key. The aad_item_data is the public key of the member_proof for the next epoch, if the commit is accepted by the group. Other members which receive a next_epoch_member_proof_key extension in the aad_items of the authenticated_data need to verify that it was sent only in a commit, and that the public key would be correct if the commit is accepted. (If the commit is already invalid for other reasons, the client does not need to continue this verification).

New Requirements on Safe Extensions framework This document depends on two new features of the Safe Extensions framework, currently documented in PRs #28 (exporting the member_proof public key) and #29 (framing/muxing of AAD) on .

Security Considerations TODO

IANA Considerations This document requests the addition of various new values under the heading of "Messaging Layer Security". Each registration is organized under the relevant registry Type. RFC EDITOR: Please replace XXXX throughout with the RFC number assigned to this document

MLS Extension Type handshake_framed_data_hash

• Value: To be assigned by IANA
• Name: handshake_framed_data_hash
• Message(s): AD: This extension may appear in SafeAADInfo objects.
• Recommended: Y
• Reference: RFC XXXX

MLS Extension Type next_epoch_member_proof_key

• Value: To be assigned by IANA
• Name: next_epoch_member_proof_key
• Message(s): GC, AD: This extension may appear in GroupContext objects and/or SafeAADInfo objects.
• Recommended: Y
• Reference: RFC XXXX

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. Phoenix R&D This document describes extensions to the Messaging Layer Security (MLS) protocol. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/mlswg/mls-extensions. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.

Acknowledgments TODO acknowledge.