Network Working Group E. Omara Internet-Draft Google Intended status: Informational R. Robert Expires: March 14, 2020 Wire September 11, 2019 The Messaging Layer Security (MLS) Federation draft-ietf-mls-federation-00 Abstract This document describes how the Messaging Layer Security (MLS) can be used in a federated environment where different MLS implementations can interoperate by defining the message format for user key retrieval. The document also describes some use cases where federation could be useful. Status of This Memo 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 March 14, 2020. Copyright Notice Copyright (c) 2019 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 Simplified BSD License text as described in Section 4.e of Omara & Robert Expires March 14, 2020 [Page 1] Internet-Draft MLS Federation September 2019 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Different Delivery Servers . . . . . . . . . . . . . . . 4 3.2. Different client applications . . . . . . . . . . . . . . 4 4. Functional Requirements . . . . . . . . . . . . . . . . . . . 4 4.1. Delivery service . . . . . . . . . . . . . . . . . . . . 4 4.1.1. Client fanout . . . . . . . . . . . . . . . . . . . . 5 4.1.2. Server fanout . . . . . . . . . . . . . . . . . . . . 5 4.2. Authentication service . . . . . . . . . . . . . . . . . 6 5. Message format . . . . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6.1. Version negotiation . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction MLS Architecture draft [MLSARCH] describes the overall MLS system architecture assuming the client and servers (Delivery Service and Authentication Service) are operated by the same entity. This document describes the minimum changes needed to allow different MLS clients operated by the same or different entities to communicate with each and explaining The use cases where federation could be useful. The focus of this document will be the interaction between the client and the Delivery Service, specifically how the client retrieves the identityKey and InitKeys for another client. There is no changes needed for the Authentication Service. Discovering which Delivery service the client communicates with is out of the scope of this document. The below diagram shows an MLS group where all clients are operated under the same deliver service: Omara & Robert Expires March 14, 2020 [Page 2] Internet-Draft MLS Federation September 2019 +------------+ + Delivery + + Service (DS) + +-----+------+ / + \ Group ********************************************************* * / + \ * * / | \ * * +--------+ +----+---+ +--------+ * * + Client 0 + + Client 1 + + Client 3 + * * +--------+ +--------+ +--------+ * * ............................. ............ * * User 0 User 1 * * * ********************************************************* one possible environment is to have different client implementations operated by the same delivery service, which will look like the diagram above, another environment is to have different or same clients operated By different delivery services: +-----------------+ +-----------------+ + Deliver Service 1 + + Deliver Service 2 + + + + + +-----------------+ +--------+--------+ | | | | | | Group ***************|*********|*******************|*********** * | | | * * | | | * * +--------+ +--------+ +--------+ * * + Client 0 + + Client 1 + + Client 3 + * * +--------+ +--------+ +--------+ * * ............................. ............ * * User 0 User 1 * * * ********************************************************* 2. Terminology 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 Omara & Robert Expires March 14, 2020 [Page 3] Internet-Draft MLS Federation September 2019 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Client: An agent that uses this protocol to establish shared cryptographic state with other clients. A client is defined by the cryptographic keys it holds. An application or user may use one client per device (keeping keys local to each device) or sync keys among a user's devices so that each user appears as a single client. User Init Key: A short-lived HPKE key pair used to introduce a new client to a group. Initialization keys are published for each client (UserInitKey). Identity Key: A long-lived signing key pair used to authenticate the sender of a message. We use the TLS presentation language [RFC8446] to describe the structure of protocol messages. 3. Use cases 3.1. Different Delivery Servers Different applications operated by different entities can use MLS to exchange E2EE messages. For example in email applications, clients of email1.com can encrypt and decrypt E2EE email messages from email2.com. 3.2. Different client applications Different client applications operated by the same server can use MLS to exchange E2EE handshake and application messages. For example different browsers can implement the MLS protocol, and web developers write web applications that use the MLS implementation in the browser to encrypt and decrypt the messages. This will require a new standard Web API to allow the client applications to set the address of the delivery service in the browser. A more concrete example is using MLS in the browser to exchange SRTP keys for multi-party conference call. 4. Functional Requirements 4.1. Delivery service In MLS environment the messages can either be delivered using client fanout or server fanout, each will have different requirements. Omara & Robert Expires March 14, 2020 [Page 4] Internet-Draft MLS Federation September 2019 In a federated environment the client may communicate with one or more delivery services. Discovering the delivery service and syncing between different delivery services are out of scope of this document. 4.1.1. Client fanout In this mode, the client SHOULD support communicating with multiple delivery services. Discovering the delivery service is out of scope of this document. +-----------------+ +---------+ + Deliver Service B + +------> + Client B1 + +----------> + + +---------+ | +-----------------+ | +---------+ | +-----------------+ +---------+ + Client A1 +-----------> + Deliver Service A + +------> + Client A2 + +---------+ | + + +---------+ | +-----------------+ | | +-----------------+ +---------+ +----------> + Deliver Service C + +------> + Client C1 + + + +---------+ +-----------------+ In this mode, the delivery service SHPULD be stateless, and it the clients responsibility to maintain the group state. OPEN QUESTION: How ordering could be enforced in this mode? 4.1.2. Server fanout Multiple delivery services can be avoided, with server side fan out, and all keys requests can be proxied through a single delivery service. The protocol between different delivery services is out of the scope of this document. Omara & Robert Expires March 14, 2020 [Page 5] Internet-Draft MLS Federation September 2019 +-----------------+ +---------+ +--> + Deliver Service B + +---> + Client B1 + | + + +---------+ | +-----------------+ | +---+-------------+ +---------+ +---------+ + Deliver Service A + +-------------> + Client A2 + + Client A1 + +---> + + +---------+ +---------+ +------+----------+ | | +-----------------+ +---------+ +--> + Deliver Service C + +---> + Client C1 + + + +---------+ +-----------------+ OPEN QUESTION: How server assist could be used with multiple servers? how the server state is shared and synced ? 4.2. Authentication service There is no change needed for the authentication service, however the authentication in a federated environment becomes more important. The ideal solution would be using a shared transparency log like [KeyTransparency]. 5. Message format The encrypted message payload is defined in the MLS protocol document [MLSPROTO], in order to get federation between different systems, the identity key and user init key retrieval MUST be defined as well. The identity key can always be included in the user init key response. Omara & Robert Expires March 14, 2020 [Page 6] Internet-Draft MLS Federation September 2019 enum { P256_SHA256_AES128GCM(0x0000), X25519_SHA256_AES128GCM(0x0001), (0xFFFF) } CipherSuite; struct { opaque identity<0..2^16-1>; CipherSuite supported_suites<0..255>; } GetUserInitKeyRequest; struct { opaque user_init_key_id<0..255>; CipherSuite cipher_suites<0..255>; HPKEPublicKey init_keys<1..2^16-1>; Credential credential; opaque signature<0..2^16-1>; } UserInitKey; struct { opaque identity<0..2^16-1>; UserInitKey user_init_key; } UserInitKeyBundle; The delivery service will return one or more user init key bundles, one for each member. struct { UserInitKeyBundle user_init_keys<0..2^32-1>; } GetUserInitKeyResponse; OPEN QUESTION: What if different clients have different cipher suites? 6. Security Considerations 6.1. Version negotiation In a federated environment, version negotiation is more critical, to avoid forcing a downgrade attack by malicious 3rd party delivery services. The negotiation could either be done in the UserInitKeyBundle or in a separate handshake message. 7. IANA Considerations This document makes no requests of IANA. Omara & Robert Expires March 14, 2020 [Page 7] Internet-Draft MLS Federation September 2019 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . 8.2. Informative References [KeyTransparency] Google, ., "Key Transparency", n.d., . [MLSARCH] Omara, E., Barnes, R., Rescorla, E., Inguva, S., Kwon, A., and A. Duric, "Messaging Layer Security Architecture", 2018. [MLSPROTO] Barnes, R., Millican, J., Omara, E., Cohn-Gordon, K., and R. Robert, "Messaging Layer Security Protocol", 2018. Authors' Addresses Emad Omara Google Email: emadomara@google.com Raphael Robert Wire Email: raphael@wire.com Omara & Robert Expires March 14, 2020 [Page 8]