]> Five9

jdrosen@jdrosen.net

Cisco

fluffy@iii.ca

Applications Mimi Internet-Draft This document outlines architecture options for managing the state of chats in MIMI.

Introduction The More Instant Messaging Interoperability (MIMI) working group will specify the minimal set of mechanisms required to make modern Internet messaging applications interoperable. Over time, messaging applications have achieved widespread use, their feature sets have broadened, and their adoption of end-to-end encryption (E2EE) has grown, but the lack of interoperability between these services continues to create a suboptimal user experience. The standards produced by the MIMI working group will allow for E2EE messaging applications for both consumer and enterprise to interoperate without undermining the security guarantees that they provide. There are a variety of options on how MIMI can work in a federated model. This draft outlines the options and suggests which one to move forward with.

Architectural Options There are numerous architectural models for building inter-provider messaging. One model, implemented in protocols like SIMPLE and XMPP , consider messaging as a problem of message transport, sending messages from one user to another user. There is no notion of message storage, though in XMPP this can be added through Multi-User Chat (MUC). Most modern messaging services implement message persistence, and thus introduce the idea of chats as a stateful resource that live within the messaging provider. A chat resource can be either a 1-1 chat, or a group chat. The state of a chat resource includes the membership in the chat group along, the history of member additions/removals, along with the history of messages posted to it. In that way, 1-1 and group chats are essentially identical. Clients can query the state of their chats at any time to catch up, and they can receive notifications when there are new chats. Sending a message is primarily a transaction between the client and their provider; the provider acknowledges the message, stores it, acknowledges the receipt of the message towards the client, and then begins to replicate the data into databases as needed, while also notifying recipients of the new message. When considering the expansion of this model to inter-provider communications, there are two ways it can work. In one approach, a particular chat resource lives within a single provider - the one where the chat resource was created. Other users, who may be supported by other providers, connect directly to this single provider to receive information about the state of that particular chat session. In this architecture, the state of a chat resource is not replicated between providers at all - it lives in a single place. Architecturally, it looks like this: A group chat, chat A, was created by user A, who is a user of provider 1. This chat and its state lives exclusively within provider 1. User B, utilizes provider 2, and user C, a user of provider 3, are members of the group chat A. Through the MIMI protocols, users B and C are able to establish connections to provider 1 in order to retrieve and send messages. We refer to this model as the "guest model", since in essence, users B and C become "guest users" or provider 1. A drawback of this model is that there is no easy way for a user to know the full set of chats - across multiple providers - in which they should retrieve messages. This model is, in essence, similar to the multi-headed chat clients of old, like Pidgin. A variation of this model is shown below. In this variation, the group chat still lives within provider 1, but users B and C connect to their respective providers to post mesasges, retrieve messages, and get notifications. Providers 2 and 3 do not store contents of the chat - they act as proxies for the purpose of authentication and trust. They also would retain knowledge of the set of chats in which their users are members, including ones like chat A which live within other providers. Let us call this the "proxied guest" model. The final model - and the one that is used by this messaging format, is shown below: In this model, the chat resource - its full state - lives within each provider. However, one provider acts as the source of truth. Through the mimi protocols and message formats, the state of this chat is synchronized to the other providers. All write operations happen against the chat resource in provider 1, and the new messages are then delivered to the other providers. For example, if user B posts a message to the group chat, user B sends that message to their provider, provider 2. Provider 2 will deliver this to provider 1. However, provider 2 will not update the state of the chat. Provider 2 may store this new message to ensure delivery to provider 1, but it is not considered as "posted" into the chat yet. Once delivered to provider 1, only then is the message considered posted. This causes a change in the state of the chat, and thus a notification of new message is sent to providers 2 and 3. Both of these providers store the new message and notify their respective users of the new message. From a user experience perspective, typical implementations have user B's UI show the new message in the chat immediately upon sending. Thus, the notification that the message was posted, acts only as a confirmation to user B. The astute reader will note there is a fourth model, wherein there is no single SoT and writes can be made to any instance of the chat resource. THis is the most complex solution, and due to the challenges of building such database systems in general - let alone making them work inter-provider - we do not suggest this approach.

Recommendations The third model - where chat resource state is replicated, but there is a single source of truth against which all write operations are performed - seems like the right model. The guest model incurs a heavy load of long-lived connections on each provider, and requires the client to maintain a connection to each provider. This doesnt seem scalable. The proxy guest model fixes this, but puts the burden of message sync and reliability in the client hands. The replicated state model addresses that, while providing the consistency required for the system to work reliably.

Normative References 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. Inria & Mozilla Mozilla Google Twitter MIT 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. Cisco Inria & Mozilla Facebook 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. The IETF has produced many specifications related to Presence and Instant Messaging with the Session Initiation Protocol (SIP). Collectively, these specifications are known as SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE). This document serves as a guide to the SIMPLE suite of specifications. It categorizes the specifications, explains what each is for, and how they relate to each other. 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] This memo defines the MIME content type 'Message/CPIM', a message format for protocols that conform to the Common Profile for Instant Messaging (CPIM) specification. [STANDARDS-TRACK]