]>

rohan.ietf@gmail.com

Security Messaging Layer Security new content type new ratchet presence status ephemeral messages istyping This Messaging Layer Security (MLS) extension adds two new variations of the application content type, each with a separate key ratchet. It also creates an MLS capability to negotiate use of the new types, and an IANA registry to register additional content types. 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 Some messaging protocols (ex: XMPP ) make a distinction between regular messages--where each message is relevant, and status or "presence" messages--where only the most recent update per sender is relevant. In addition, some messages may have a sufficiently short relevance (for example, typing notifications) that they can be discarded if the receiver is offline. In large messaging systems with lots of updates, optimizing decryption of such messages, and optionally suppressing delivery of irrelevant message can result in improved performance. This document defines two new MLS content types: status and ephemeral. These largely act like the application content type, but the new content types each maintain distinct key ratchets in the secret tree. Only the most recent status message of a particular type from each sender needs to be decrypted. Only ephemeral messages received within a small amount of time (ex: 30 seconds) are relevant (and of those only the most recent per type from each sender). This allows an application to fast-forward over generations that contain irrelevant messages.

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 uses many terms and structures from MLS , and terms and concepts discussed in the MLS Architecture , including the term Distribution Service (DS).

Negotiating Support If a client supports the mechanism in this document, it adds a supported_content_types extension to its LeafNode.Capabilities.ExtensionTypes with the specific non-default content types it supports (for example, status and/or ephemeral in this specification). If an MLS group GroupContext.RequiredCapabilities.extension_types contains a required_content_types extension, every member of the MLS group MUST be prepared to receive messages with any of the (non-default) content types listed. It also redefines the ContentType enum as shown below. ; } ContentTypes; ContentTypes supported_content_types; ContentTypes required_content_types; ]]>

Sending and Receiving If a group lists a specific content type in its required_content_types as described in the previous section, a member MAY send an MLS PrivateMessage with that content type. The construction of the PrivateMessage is the same as for sending an application message, except that the per-sender ratchet is used derived from the relevant content type, as shown in the figure below, which replaces Figure 26 of , and the new version of three structs defined later in this section (FramedContent, FramedContentAuthData, and PrivateMessgeContent) replace those defined in :

Initialization of the Hash Ratchets from the Leaves of a Secret Tree ExpandWithLabel(., "handshake", "", KDF.Nh) | = handshake_ratchet_secret_[N]_[0] | +--> ExpandWithLabel(., "application", "", KDF.Nh) | = application_ratchet_secret_[N]_[0] | +--> ExpandWithLabel(., "status", "", KDF.Nh) | = status_ratchet_secret_[N]_[0] | +--> ExpandWithLabel(., "ephemeral", "", KDF.Nh) = ephemeral_ratchet_secret_[N]_[0] ]]>

; uint64 epoch; Sender sender; opaque authenticated_data; ContentType content_type; select (FramedContent.content_type) { case application: case status: case ephemeral: opaque application_data; case proposal: Proposal proposal; case commit: Commit commit; }; } FramedContent; struct { /* SignWithLabel(., "FramedContentTBS", FramedContentTBS) */ opaque signature; select (FramedContent.content_type) { case commit: /* MAC(confirmation_key, GroupContext.confirmed_transcript_hash) */ MAC confirmation_tag; case application: case status: case ephemeral: case proposal: struct{}; }; } FramedContentAuthData; struct { select (PrivateMessage.content_type) { case application: case status: case ephemeral: opaque application_data; case proposal: Proposal proposal; case commit: Commit commit; }; FramedContentAuthData auth; opaque padding[length_of_padding]; } PrivateMessageContent; ]]> All clients in a group need to agree on the "maximum number of steps that clients will move a secret tree ratchet forward in response to a single message before rejecting it" as described in . If a client is about to exhaust that number of steps for its own status or ephemeral ratchet, it MUST send a new commit. A policy for conveying that number is described as OperationalParamaters.app_message_policy.max_generations_skipahead in . On receipt of a PrivateMessage with a supported, non-default content type, the receiver first determines if it is outdated. If the content is an ephemeral content type older than its handling threshold, (ex: older than several minutes), the recipient can drop the message. If the content is a status content type, and the client has a more recent status message of the same type from the same sender, the client can drop the message. If the message is not outdated, the client decrypts the message using the relevant ratchet.

DS Behavior A DS MAY discard messages with an ephemeral content type which are considered "old" by the application (ex: several minutes). A DS which knows the identity of the sender of a message and the type of status message, MAY discard status messages when there is a newer status message of the same type from the same sender. (For example, the type of status could be administratively limited to a single type, presented out-of-band, or in the Additional Authenticated Data of the message.)

Security Considerations Use of one of the two content types defined here might allow the MLS DS (an on-path potential adversary) to infer more about the state of the sending client, by separating regular message, status message, and ephemeral message classes. However, the additional advantage is unlikely to reveal information not already available during timing and traffic analysis. Adding new content types potentially increases the amount of keying material that needs to be kept per member, however this mechanism allows for clients to aggressively throw away old generations without decrypting irrelevant messages. Clients MUST verify the authenticity of messages sent with these content types before deleting older generations. If the volume of messages using these content types regularly exceeds the number of ratchet steps (in instant messaging applications, typically around 10,000 steps), this extension could cause an increase in the number of Commit messages sent.

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. This document also requests the creation of a new MLS Content Types registry as described in . RFC EDITOR: Please replace XXXX throughout with the RFC number assigned to this document.

MLS Extension Types

supported_content_types MLS Extension The supported_content_types MLS Extension Type is used inside LeafNode objects. It contains a list of non-default ContentTypes supported by the client node. Value: 0x0009 (suggested) Name: supported_content_types Message(s): LN: This extension may appear in LeafNode objects Recommended: Y Reference: RFC XXXX

required_content_types MLS Extension The required_content_types MLS Extension Type is used inside GroupContext objects. It contains a list of non-default ContentTypes that are mandatory for all MLS members of the group to support. Value: 0x000a (suggested) Name: required_content_types Message(s): GC: This extension may appear in GroupContext objects Recommended: Y Reference: RFC XXXX

MLS Content Types This document requests the creation of a new IANA "MLS Content Types" registry under the "Messaging Layer Security" group registry heading. Assignments are via the Specification Required policy using the MLS Designated Experts. Template:

• Value: The numeric value of the component ID
• Name: The name of the component
• Recommended: Same as in Section 17.1 of
• Reference: The document where this content type is defined

Initial Contents:

Value	Name	R	Ref
0x00	RESERVED	-	RFC9420
0x01	application	Y	RFC9420
0x02	proposal	Y	RFC9420
0x03	commit	Y	RFC9420
0x04	status	Y	RFCXXXX
0x05	ephemeral	Y	RFCXXXX
0x06-
0xff	UNASSIGNED	-	RFC9420

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. The Messaging Layer Security (MLS) protocol (RFC 9420) provides a group key agreement protocol for messaging applications. MLS is designed to protect against eavesdropping, tampering, and message forgery, and to provide forward secrecy (FS) and post-compromise security (PCS). This document describes the architecture for using MLS in a general secure group messaging infrastructure and defines the security goals for MLS. It provides guidance on building a group messaging system and discusses security and privacy trade-offs offered by multiple security mechanisms that are part of the MLS protocol (e.g., frequency of public encryption key rotation). The document also provides guidance for parts of the infrastructure that are not standardized by MLS and are instead left to the application. While the recommendations of this document are not mandatory to follow in order to interoperate at the protocol level, they affect the overall security guarantees that are achieved by a messaging application. This is especially true in the case of active adversaries that are able to compromise clients, the Delivery Service (DS), or the Authentication Service (AS). Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. Informative References The Extensible Messaging and Presence Protocol (XMPP) is an application profile of the Extensible Markup Language (XML) that enables the near-real-time exchange of structured yet extensible data between any two or more network entities. This document defines XMPP's core protocol methods: setup and teardown of XML streams, channel encryption, authentication, error handling, and communication primitives for messaging, network availability ("presence"), and request-response interactions. This document obsoletes RFC 3920. [STANDARDS-TRACK] Rohan Mahy Consulting Services This document describes a set of concrete room policies for the More Instant Messaging Interoperability (MIMI) Working Group. It describes several independent properties and policy attributes which can be combined to model a wide range of chat and multimedia conference types.

Acknowledgments TODO acknowledge.