]>

rohan.ietf@gmail.com

Security Messaging Layer Security GroupContext hash FramedContent FramedContentTBS efficient signing deterministic signing Most MLS signatures are signed over the relatively large GroupContext structure. This document defines a way to safely sign using a pre-hashed version of the GroupContext structure for better efficiency. 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 In MLS all in-member application, commit, and proposal messages (whether sent via a PublicMessage, PrivateMessage or SemiPrivateMessage ); and all external commits contain a signature of the FramedContentTBS structure. This structure contains the full GroupContext of the group, which can store a large amount of group state. (For example, in the MIMI protocol it contains the participant list for the group, which could contain thousands of URIs.) The GroupContext only changes once per epoch, therefore it is an excellent candidate to pre-hash and cache for efficiency reasons. Having to fetch the entire GroupContext also negatively impacts mobile clients that process new messages in the background. This document defines a replacement for the FramedContentTBS structure that uses a pre-hashed GroupContext, and an MLS extension for safely negotiating the use of the new struct. This same improvement could be incorporated into the SlimFramedContentTBS struct in Slim MLS .

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.

Mechanism This document defines the new_framed_content_tbs extension. When present in a LeafNode.capabilities.extensions list, it indicates that the client supports this extension. When present in the required_capabilities.extension_types list in GroupContext.extensions it indicates that every member of the group MUST use the new FramedContentTBS structure. The FramedContentTBS structure is replaced with the new structure below. The only change is that the GroupContext is replaced with context_hash: a hash (using the current hash function from the group's MLS cipher suite) of the GroupContext. Since the context_hash can be cached for an entire epoch, this can result in a substantial efficiency improvement for additional messages sent during the same epoch. ; case external: case new_member_proposal: struct{}; }; } FramedContentTBS; ]]>

Security Considerations This proposal replaces the GroupContext with the hash of the GroupContext. The primary security consequence of this change is that if a non-member is aware of the context_hash, but not the entire GroupContext, it can still validate member signatures. This may have minor privacy implications.

IANA Considerations This document requests the addition of a new MLS Extension Type value under the heading of "Messaging Layer Security". RFC EDITOR: Please replace XXXX throughout with the RFC number assigned to this document. The new_framed_content_tbs MLS Extension Type is used inside LeafNode and GroupContext objects. In a LeafNode it indicates support the the extension. In the required_capabilities of the GroupContext it indicates the extension is being used. Value: 0x000b (suggested) Name: new_framed_content_tbs Message(s): GC,LN: This extension may appear in GroupContext and LeafNode objects Recommended: Y Reference: RFC XXXX

References 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. 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. Informative References Rohan Mahy Consulting Services This document defines a SemiPrivateMessage for the Messaging Layer Security (MLS) protocol. It allows members to share otherwise private commits and proposals with a designated list of external receivers rather than send these handshakes in a PublicMessage. Cisco The Matrix.org Foundation C.I.C. Phoenix R&D Rohan Mahy Consulting Services The Matrix.org Foundation C.I.C. Phoenix R&D This document specifies the More Instant Messaging Interoperability (MIMI) transport protocol, which allows users of different messaging providers to interoperate in group chats (rooms), including to send and receive messages, share room policy, and add participants to and remove participants from rooms. MIMI describes messages between providers, leaving most aspects of the provider-internal client- server communication up to the provider. MIMI integrates the Messaging Layer Security (MLS) protocol to provide end-to-end security assurances, including authentication of protocol participants, confidentiality of messages exchanged within a room, and agreement on the state of the room. Phoenix R&D Phoenix R&D This document defines SlimMLS, an extension to the Messaging Layer Security (MLS) protocol for reducing wire and per-client storage overhead in groups that use ciphersuites with large public keys, ciphertexts, signatures, and credentials. SlimMLS replaces many large objects that appear in MLS authenticated or transcript-hashed structures with typed hash references. Clients resolve the referenced objects only when needed, using a per-message carrier, a local cache, or an application-specific retrieval channel. The extension is most useful when an independent Delivery Service can assist with retrieval and per-recipient delivery, although local caching and delayed fetching also help without such assistance. SlimMLS defines slim variants of KeyPackage, Commit, Welcome, GroupInfo, and message framing. When placing a signature outside an encrypted envelope would reveal the signer, SlimMLS keeps the signature inside the ciphertext.