| Internet-Draft | MIMI problem outline | March 2023 |
| Mahy | Expires 14 September 2023 | [Page] |
Instant Messaging interoperability requirements have changed dramatically since the last IETF activity in the space. This document presents an outline of problems that need to be addressed to make possible interoperability of modern Instant Messaging systems. The goal of this problem outline is to point at more detailed drafts which spawn discussion and eventually spur the IETF standards process.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 14 September 2023.¶
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The IETF has been working on Instant Messaging Interoperability since the late 1990s. At the time, different groups within IETF proposed separate protocol suites (SIMPLE, APEX, and XMPP) because the community could not come to consensus on a single protocol (arguably due to a lack of consensus on the additional requirements which made these proposals unique). In the interests of interoperability, the IMPP Working Group developed a general framework for interoperability [RFC3860], and the Common Presence and Instant Messaging (CPIM) Message Format [RFC3862], an interoperability format that could pass through gateways among these protocols, even when end-to-end encrypted.¶
The CPIM model assumed standalone encryption of each message using a protocol such as S/MIME [RFC8551] or PGP [RFC3156]. This model was not widely adopted, but many Instant Messaging systems around this time frame began to add optional end-to-end encryption with OTR (Off The Record) [OTR], and eventually incorporated variants of the Double Ratchet protocol [DoubleRatchet], originally popularized by Signal.¶
Today, group chats are the norm, most modern instant messaging systems are end-to-end encrypted (many by default or always) using a variant of DoubleRatchet, and the typical feature set includes a plethora of features not included in CPIM: plain text and rich text messaging, delivery notifications, read receipts, replies, reactions, editing or deleting previously sent messages, and expiring messages. Almost all systems provide a way to share files/audio/videos, and many support calling and/or conferencing features (often using WebRTC). Some IM vendors are implementing MLS [I-D.ietf-mls-protocol], a group key establishment protocol motivated by the desire for group chat with efficient end-to-end encryption.¶
Unfortunately, federation of these IM systems is still rare and interoperability of the major IM systems in almost non-existent. It would be incredibly beneficial to provide interoperable best practices and solutions which IM vendors can incorporate into modern IM systems. Indeed, large customers and governments are already putting pressure on these IM vendors. The European Union's Digital Markets Act Article 7 [DMA] is a recent motivator as well.¶
Instant Messaging interoperability requirements have changed dramatically since the IETF last activity in the space. This document presents an outline of problems that need to be addressed to make possible interoperability of modern Instant Messaging systems. The goal of this problem outline is to point at more detailed drafts which spur discussion and eventually spur the IETF standards process.¶
The larger goals of MIMI (More Instant Messaging Interoperability) are to start discussion; gather requirements common to many IM systems, focusing on the most immediate needs first; develop requirements and frameworks; and eventually to identify and evaluate existing solutions to these specific problems; and to assemble standards and technology which already largely exist into profiles and best current practices. Where special expertise in another Working Group or standards body is required, that work would be delegated to the specialty group.¶
IM systems have a number of identifiers with different characteristics which are relevant for interoperability.¶
These identifiers are discussed in detail in [I-D.mahy-mimi-identity] as well as how they can be represented using URIs.¶
The largest and most widely deployed Instant Messaging (IM) systems support end-to-end message encryption using a variant of the Double Ratchet protocol [DoubleRatchet] popularized by Signal and the companion X3DH [X3DH] key agreement protocol. Many vendors are also keen to support the Message Layer Security (MLS) protocol [I-D.ietf-mls-protocol] and architecture [I-D.ietf-mls-architecture]. These protocols provide confidentiality of sessions (with Double Ratchet) and groups (with MLS) once the participants in a conversation have been identified. However, the current state of most systems require the end user to manually verify key fingerprints or blindly trust their instant messaging service not to add and remove participants from their conversations. This problem is exacerbated when these systems federate or try to interoperate.¶
This problem space is explored in [I-D.mahy-mimi-identity], and a specific architecture is described in [I-D.barnes-mimi-identity-arch].¶
The discovery of IM services using DNS SRV records is described in [RFC3861].¶
TBC.¶
One vendor mentioned a strawperson outline for user discovery:¶
well-known URL with query format on each domain¶
The privacy implications of user discovery are of the utmost importance, and may differ widely depending on the specific messaging application.¶
Enabling strong user privacy has been a core concern of the IETF for decades, and was the main motivation for the CPIM message format. S/MIME and PGP where proposed for use with instant messaging systems, but never widely adopted. The first broad adoption of end-to-end encryption in messaging was with Off The Record (OTR) [OTR] introduced in 2004, which also included perfect forward secrecy (which protects past communications from future compromises). As OTR was available in XMPP clients, it was possible to use across domains.¶
Signal introduced what is now know as the Double Ratchet protocol in 2013. Today there are over a dozen implementations of variations of Double Ratchet. While the differences among these variations tend to be small, there is little emphasis on interoperability.¶
Tens of instant messaging applications implement some form of end-to-end encryption using a protocol based on the Double Ratchet protocol. Double Ratchet was originally referred to as Axolotl Ratchet when it was introduced in 2013 and popularized in the Signal application. Most applications using Double Ratchet also use [X3DH] for initial key agreement. However the initial setup of encryption sessions among these applications are often incompatible.¶
Most implementations of Double Ratchet use a fixed ciphersuite and have no content negotiation or advertisement mechanism.¶
Messaging Layer Security (MLS) [I-D.ietf-mls-protocol] is a group key agreement protocol with application message encryption and authentication. As described in the MLS architecture [I-D.ietf-mls-architecture], the protocol does not define the specific behavior of the Distribution Service (DS) or the Authentication Service (AS).¶
Some specific issues involving the use of MLS is a multi-domain Instant Messaging context are discussed in the MLS federation draft [I-D.ietf-mls-federation].¶
More documentation on the use of MLS in the Instant Messaging Context: (ex: long-lived persistent groups) would be invaluable.¶
Protocol independent content negotiation is discussed in [RFC2703]. In this framework, content negotiation covers these elements:¶
In end-to-end encrypted group messaging, the problem is slightly different; an intermediary should not be able to read the sender's content, let alone change the format of the message for different recipients. Furthermore, in MLS a message in a group is encrypted once for all the recipients in the group, some of whom may be offline and receive the message later. The sender has one opportunity to craft an encrypted message which can be processed by all the members of an MLS group. Rather than have a protocol to exchange capabilities, MLS content advertising insures that each member knows any media types required in the group, knows the content capabilities of every group member at all times, and knows the media type of each received message. Note that the message could be be a container type such as a multipart [RFC2046] expressing different alternative expressions of the same content in a single message.¶
The requirements for content negotiation are discussed in the MLS architecture document [I-D.ietf-mls-architecture] and a specific content advertisement mechanism for MLS is described in [I-D.ietf-mls-extensions].¶
The expectation of basic or common features in IM systems has grown. Below is a list of some features commonly found in most IM group chat systems:¶
Once messages are encrypted end-to-end there is no further opportunity for content negotiation. Exploring requirements, semantics, and an example common format for messages, which would allow proprietary messages or extensions to be delivered in parallel to the same users is described in [I-D.mahy-mimi-content]. It discusses all of the features above.¶
The protocol used between two different providers needs to be specified. A few different proposals include creating a REST-based protocol [I-D.rosenberg-mimi-protocol], using XMPP [RFC6120], and using a variation of the Matrix protocol.¶
Many IM systems offer 1:1 calling and/or conferencing of real-time audio and video. The majority of these systems use a exchange a session description offer and answer to setup sessions of media transmitted using DTLS-SRTP [RFC5764], including the fingerprint of the DTLS-SRTP self-signed certificate. These messages are typically end-to-end encrypted. During 1:1 calls, the session descriptions (an offer and an answer) are shared for one or more DTLS-SRTP flows which carry the actual media.¶
For conferences, a client typically contacts a conferencing system which sets up a session between the client and the media forwarder. The client needs to have the URI of the specific conference and support the protocol used to access it, such as WebRTC [RFC8825] or SIP [RFC3261]. To maintain the privacy of the media with respect to the media forwarder, the clients could further encrypt the media using keying material only to clients, for example using WebRTC Insertable Streams.¶
(ex: agreement on certificates, contact information, abuse policies). TBC.¶
This document requires no action of IANA.¶