]> The Matrix.org Foundation C.I.C.

travisr@matrix.org

Applications and Real-Time More Instant Messaging Interoperability next generation unicorn sparkling distributed ledger This document introduces a set of terminology to use when discussing or describing concepts within MIMI. 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 More Instant Messaging Interoperability Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction The More Instant Messaging Interoperability (MIMI) working group is chartered to specify the minimal set of mechanisms to make modern instant messaging applications interoperable. Through prior discussions and upcoming documents, it's become important to have a shared understanding for what is being discussed specifically. This document expands upon MLS's terminology by defining terms specific to MIMI's purpose. Document authors SHOULD prefix terms from the MLS specification with "MLS" to denote that the term is specifically coming from the MLS specification. For example, "MLS Group" versus "Group". This document defines terms which are non-conflicting to help ensure clarity when the MLS prefix is missing, however. Documents within the MIMI working group may introduce their own terminology to explain concepts within their context. Those documents SHOULD NOT override or change the terminology described in this document or from MLS.

Terminology MIMI defines: User: A (normally) human operator of a client. Users have a User ID to identify them canonically within the system. Client: A user interface for messaging, performing encryption as needed. Presents conversations to the user to interact with. Synonymous with MLS Client. Clients have a Client ID to canonically identify them among a user's other clients. Conversation: The place where users communicate. Depending on design, this may be synonymous with an MLS Group. The default assumption if not clarified is that the conversation and group are different concepts/entities. Conversations have a Conversation ID to canonically identify them within the system, which may be a Group ID if the concepts are synonymous. Conversation Member: A user's membership in relation to a conversation. If the concepts of conversation and MLS Group are synonymous, this will be no different than an MLS Member, however if different then this will be which represents the MLS Member to the conversation. Event: The container for an encrypted MLS Message, sent over the wire between servers and clients (through their local servers). Events have an Event ID to canonically identify them at least within the conversation. Conversation Property: Information stored in the conversation, such as the name, topic, avatar, conversation membership, etc. This may be in the shape of an event. Note that conversation properties are different from what is needed to construct an MLS Group Context. Message: Synonymous with an MLS Message. Messages have a Message ID to canonically identify them at least within the group. Server: Synonymous with an MLS Delivery Service (DS). Responsible for routing events to other servers and local clients. Note that the role of a server can be accomplished in the same logical place as a client (i.e.: in peer-to-peer environments), however the default assumption if not clarified is that the client and server are two different entities. Client-Server API: The interface between a client and server. This may be nothing more than a function call if the client and server are the same logical entity. Server-Server API: The interface between a server and another server. Transport: The method and format for moving information between entities. For example, a Client-Server API might describe HTTPS and JSON as its transport. For added clarity, documents should clarify which API surface they are defining a transport for ("Server-Server Transport", for example). Access Control: The set of algorithms which determine whether an event or MLS Message is permitted in the conversation/group. For instance, this may define whether an MLS Proposal is accepted or whether the user is able to become a conversation member. Message Format: The specific format that clients use within the encrypted body of an MLS Message. Sometimes this will also be called the Content Format. User Identity: A mapping of User ID to external identifier, such as a phone number. In some cases, the user identity can be synonymous with the user ID, however the default assumption if not clarified is that they are different concepts. Messaging Provider or Provider: A service offering instant messaging to users. Typically a provider will have a server to route events between users (or clients, specifically).

Diagram Reference In the simplest possible form, interoperable messaging between two end users looks as such:

Typical, simplified, architecture for interoperability | Provider 1 |<----->| Provider 2 |<----->| Client 2 | | | | | | | | | +----------+ +------------+ +------------+ +----------+ ^ ^ | D | +-------------------------------------------------------------+ ]]>

In this figure, Client 1 is directly connected to Provider 1 over channel A. A is a provider-specific Client-Server API and transport. Similarly, Client 2 is directly connected to Provider 2 over channel C. C is also a provider-specific Client-Server API and transport. Provider 1 and 2 talk to each other with a Server-Server API over a transport. This is B in the figure. Clients additionally have an implicit channel (D in the figure) where they use a shared Message Format. There is no transport for D in this figure: the figure is denoting that servers/providers are unable to assist with a format conversion due to the event's content (an MLS message) being encrypted.

IANA Considerations This document has no IANA actions.

Normative References Cisco Inria & Mozilla Phoenix R&D Meta Platforms Google University of Oxford 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 and post-compromise security for groups in size ranging from two to thousands. Inria & Mozilla Mozilla Google Twitter Wire The Messaging Layer Security (MLS) protocol (I-D.ietf-mls-protocol) specification has the role of defining a Group Key Agreement protocol, including all the cryptographic operations and serialization/deserialization functions necessary for scalable and secure group messaging. The MLS protocol is meant to protect against eavesdropping, tampering, message forgery, and provide further properties such as Forward Secrecy (FS) and Post-Compromise Security (PCS) in the case of past or future device compromises. This document describes a general secure group messaging infrastructure and its security goals. It provides guidance on building a group messaging system and discusses security and privacy tradeoffs 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 the MLS Protocol document and left to the application or the infrastructure architects to design. 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 case of active adversaries that are able to compromise clients, the delivery service, or the authentication service.