idnits 2.17.1 draft-ietf-mls-architecture-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-mls-protocol]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 561: '... SHOULD be stored encrypted at rest....' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (16 June 2022) is 678 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'BBN19' is mentioned on line 1693, but not defined == Missing Reference: 'ACDT21' is mentioned on line 1693, but not defined == Missing Reference: 'AJM20' is mentioned on line 1698, but not defined == Missing Reference: 'BBR18' is mentioned on line 1698, but not defined == Missing Reference: 'ACDT19' is mentioned on line 1698, but not defined == Missing Reference: 'ACCKKMPPWY19' is mentioned on line 1698, but not defined == Missing Reference: 'ACJM20' is mentioned on line 1698, but not defined == Missing Reference: 'BCK21' is mentioned on line 1700, but not defined == Missing Reference: 'CHK19' is mentioned on line 1701, but not defined == Outdated reference: A later version (-20) exists of draft-ietf-mls-protocol-14 Summary: 2 errors (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Beurdouche 3 Internet-Draft Inria & Mozilla 4 Intended status: Informational E. Rescorla 5 Expires: 18 December 2022 Mozilla 6 E. Omara 7 Google 8 S. Inguva 9 Twitter 10 A. Kwon 11 MIT 12 A. Duric 13 Wire 14 16 June 2022 16 The Messaging Layer Security (MLS) Architecture 17 draft-ietf-mls-architecture-08 19 Abstract 21 The Messaging Layer Security (MLS) protocol [I-D.ietf-mls-protocol] 22 specification has the role of defining a Group Key Agreement 23 protocol, including all the cryptographic operations and 24 serialization/deserialization functions necessary for scalable and 25 secure group messaging. The MLS protocol is meant to protect against 26 eavesdropping, tampering, message forgery, and provide further 27 properties such as Forward Secrecy (FS) and Post-Compromise Security 28 (PCS) in the case of past or future device compromises. 30 This document describes a general secure group messaging 31 infrastructure and its security goals. It provides guidance on 32 building a group messaging system and discusses security and privacy 33 tradeoffs offered by multiple security mechanisms that are part of 34 the MLS protocol (e.g., frequency of public encryption key rotation). 36 The document also provides guidance for parts of the infrastructure 37 that are not standardized by the MLS Protocol document and left to 38 the application or the infrastructure architects to design. 40 While the recommendations of this document are not mandatory to 41 follow in order to interoperate at the protocol level, they affect 42 the overall security guarantees that are achieved by a messaging 43 application. This is especially true in case of active adversaries 44 that are able to compromise clients, the delivery service, or the 45 authentication service. 47 Discussion Venues 48 This note is to be removed before publishing as an RFC. 50 Discussion of this document takes place on the MLS Working Group 51 mailing list (mls@ietf.org), which is archived at 52 https://mailarchive.ietf.org/arch/browse/mls/. 54 Source for this draft and an issue tracker can be found at 55 https://github.com/mlswg/mls-architecture. 57 Status of This Memo 59 This Internet-Draft is submitted in full conformance with the 60 provisions of BCP 78 and BCP 79. 62 Internet-Drafts are working documents of the Internet Engineering 63 Task Force (IETF). Note that other groups may also distribute 64 working documents as Internet-Drafts. The list of current Internet- 65 Drafts is at https://datatracker.ietf.org/drafts/current/. 67 Internet-Drafts are draft documents valid for a maximum of six months 68 and may be updated, replaced, or obsoleted by other documents at any 69 time. It is inappropriate to use Internet-Drafts as reference 70 material or to cite them other than as "work in progress." 72 This Internet-Draft will expire on 18 December 2022. 74 Copyright Notice 76 Copyright (c) 2022 IETF Trust and the persons identified as the 77 document authors. All rights reserved. 79 This document is subject to BCP 78 and the IETF Trust's Legal 80 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 81 license-info) in effect on the date of publication of this document. 82 Please review these documents carefully, as they describe your rights 83 and restrictions with respect to this document. Code Components 84 extracted from this document must include Revised BSD License text as 85 described in Section 4.e of the Trust Legal Provisions and are 86 provided without warranty as described in the Revised BSD License. 88 Table of Contents 90 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 91 2. General Setting . . . . . . . . . . . . . . . . . . . . . . . 4 92 2.1. Group Members and Clients . . . . . . . . . . . . . . . . 7 93 3. Authentication Service . . . . . . . . . . . . . . . . . . . 8 94 4. Delivery Service . . . . . . . . . . . . . . . . . . . . . . 9 95 4.1. Key Storage . . . . . . . . . . . . . . . . . . . . . . . 10 96 4.2. Key Retrieval . . . . . . . . . . . . . . . . . . . . . . 10 97 4.3. Delivery of Messages . . . . . . . . . . . . . . . . . . 11 98 4.4. Membership knowledge . . . . . . . . . . . . . . . . . . 12 99 4.5. Membership and offline members . . . . . . . . . . . . . 13 100 5. Functional Requirements . . . . . . . . . . . . . . . . . . . 13 101 5.1. Membership Changes . . . . . . . . . . . . . . . . . . . 13 102 5.2. Parallel Groups . . . . . . . . . . . . . . . . . . . . . 14 103 5.3. Asynchronous Usage . . . . . . . . . . . . . . . . . . . 15 104 5.4. Access Control . . . . . . . . . . . . . . . . . . . . . 15 105 5.5. Recovery After State Loss . . . . . . . . . . . . . . . . 16 106 5.6. Support for Multiple Devices . . . . . . . . . . . . . . 16 107 5.7. Extensibility . . . . . . . . . . . . . . . . . . . . . . 17 108 5.8. Application Data Framing and Negotiation . . . . . . . . 17 109 5.9. Federation . . . . . . . . . . . . . . . . . . . . . . . 17 110 5.10. Compatibility with Future Versions of MLS . . . . . . . . 18 111 6. Operational Requirements . . . . . . . . . . . . . . . . . . 18 112 7. Security and Privacy Considerations . . . . . . . . . . . . . 21 113 7.1. Assumptions on Transport Security Links . . . . . . . . . 22 114 7.1.1. Metadata Protection for Unencrypted Group 115 Operations . . . . . . . . . . . . . . . . . . . . . 22 116 7.1.2. DoS protection . . . . . . . . . . . . . . . . . . . 23 117 7.1.3. Message Suppression and Error Correction . . . . . . 24 118 7.2. Intended Security Guarantees . . . . . . . . . . . . . . 24 119 7.2.1. Message Secrecy and Authentication . . . . . . . . . 25 120 7.2.2. Forward and Post-Compromise Security . . . . . . . . 25 121 7.2.3. Non-Repudiation vs Deniability . . . . . . . . . . . 26 122 7.3. Endpoint Compromise . . . . . . . . . . . . . . . . . . . 26 123 7.3.1. Compromise of AEAD key material . . . . . . . . . . . 27 124 7.3.2. Compromise of the Group Secrets of a single group for 125 one or more group epochs . . . . . . . . . . . . . . 28 126 7.3.3. Compromise by an active adversary with the ability to 127 sign messages . . . . . . . . . . . . . . . . . . . . 29 128 7.3.4. Compromise of the authentication with access to a 129 signature key . . . . . . . . . . . . . . . . . . . . 29 130 7.3.5. Security consideration in the context of a full state 131 compromise . . . . . . . . . . . . . . . . . . . . . 30 132 7.4. Service Node Compromise . . . . . . . . . . . . . . . . . 31 133 7.4.1. General considerations . . . . . . . . . . . . . . . 31 134 7.4.2. Delivery Service Compromise . . . . . . . . . . . . . 32 135 7.4.3. Authentication Service Compromise . . . . . . . . . . 34 136 7.5. Considerations for attacks outside of the threat model . 36 137 7.6. Cryptographic Analysis of the MLS Protocol . . . . . . . 37 138 8. Informative References . . . . . . . . . . . . . . . . . . . 37 139 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 140 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 141 10.1. Normative References . . . . . . . . . . . . . . . . . . 38 142 10.2. Informative References . . . . . . . . . . . . . . . . . 38 143 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 39 144 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 146 1. Introduction 148 RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH 150 The source for this draft is maintained in GitHub. Suggested changes 151 should be submitted as pull requests at https://github.com/mlswg/mls- 152 architecture. Instructions are on that page as well. Editorial 153 changes can be managed in GitHub, but any substantive change should 154 be discussed on the MLS mailing list. 156 End-to-end security is a requirement for instant messaging systems 157 and is commonly deployed in many such systems. In this context, 158 "end-to-end" captures the notion that users of the system enjoy some 159 level of security -- with the precise level depending on the system 160 design -- even in the face of malicious actions by the operator of 161 the messaging system. 163 Messaging Layer Security (MLS) specifies an architecture (this 164 document) and a protocol [I-D.ietf-mls-protocol] for providing end- 165 to-end security in this setting. MLS is not intended as a full 166 instant messaging protocol but rather is intended to be embedded in 167 concrete protocols, such as XMPP [RFC6120]. Implementations of the 168 MLS protocol will interoperate at the cryptographic level, though 169 they may have incompatibilities in terms of how protected messages 170 are delivered, contents of protected messages, and identity/ 171 authentication infrastructures. The MLS protocol has been designed 172 to provide the same security guarantees to all users, for all group 173 sizes, even when it reduces to only two users. 175 2. General Setting 177 Informally, a group is a set of users who possibly use multiple 178 endpoint devices to interact with the Service Provider (SP). A group 179 may be as small as two members (the simple case of person to person 180 messaging) or as large as thousands. 182 In order to communicate securely, users initially interact with 183 services at their disposal to establish the necessary values and 184 credentials required for encryption and authentication. 186 The Service Provider presents two abstract functionalities that allow 187 clients to prepare for sending and receiving messages securely: 189 * An Authentication Service (AS) functionality which is responsible 190 for attesting to bindings between application-meaningful 191 identifiers and the public key material used for authentication in 192 the MLS protocol. This functionality must also be able to 193 generate credentials that encode these bindings and validate 194 credentials provided by MLS clients. 196 * A Delivery Service (DS) functionality which can receive and 197 distribute messages between group members. In the case of group 198 messaging, the delivery service may also be responsible for acting 199 as a "broadcaster" where the sender sends a single message which 200 is then forwarded to each recipient in the group by the DS. The 201 DS is also responsible for storing and delivering initial public 202 key material required by MLS clients in order to proceed with the 203 group secret key establishment that is part of the MLS protocol. 205 For convenience, this document adopts the representation of these 206 services being standalone servers, however the MLS protocol design is 207 made so that this is not necessarily the case. These services may 208 reside on the same server or different servers; they may be 209 distributed between server and client components; and they may even 210 involve some action by users. For example: 212 * Several secure messaging services today provide a centralized DS, 213 and rely on manual comparison of clients' public keys as the AS. 215 * MLS clients connected to a peer-to-peer network could instantiate 216 a decentralized DS by transmitting MLS messages over that network. 218 * In an MLS group using a PKI for authentication, the AS would 219 comprise the certificate issuance and validation processes, both 220 of which involve logic inside MLS clients as well as various 221 servers. 223 It is important to note that the Authentication Service functionality 224 can be completely abstract in the case of a Service Provider which 225 allows MLS clients to generate, redistribute and validate their 226 credentials themselves. 228 Similarly to the AS, the Delivery Service can be completely abstract 229 if users are able to distribute credentials and messages without 230 relying on a central Delivery Service. Note, though, that the MLS 231 protocol requires group operation messages to be processed in-order 232 by all MLS clients. 234 In some sense, a set of MLS clients which can achieve the AS and DS 235 functionalities without relying on an external party do not need a 236 Service Provider. 238 +----------------+ +--------------+ 239 | Authentication | | Delivery | 240 | Service (AS) | | Service (DS) | 241 +----------------+ +-------+------+ 242 / | \ Group 243 / ........|........\................ 244 / . | \ . 245 +--------+-+ . +----+-----+ +----------+ . 246 | Client 1 | . | Client 2 | | Client 3 | . 247 +----------+ . +----------+ +----------+ . 248 . Member 1 Member 2 . 249 . . 250 .................................. 252 In many systems, the AS and the DS are actually operated by the same 253 entity and may even be the same server. However, they are logically 254 distinct and, in other systems, may be operated by different 255 entities. Other partitions are also possible, such as having a 256 separate directory functionality or service. 258 According to this architecture design, a typical group messaging 259 scenario might look like this: 261 1. Alice, Bob and Charlie create accounts with a service provider 262 and obtain credentials from the AS. 264 2. Alice, Bob and Charlie authenticate to the DS and store some 265 initial keying material which can be used to send encrypted 266 messages to them for the first time. This keying material is 267 authenticated with their long-term credentials. 269 3. When Alice wants to send a message to Bob and Charlie, she 270 contacts the DS and looks up their initial keying material. She 271 uses these keys to establish a new set of keys which she can use 272 to send encrypted messages to Bob and Charlie. She then sends 273 the encrypted message(s) to the DS, which forwards them to the 274 recipients. 276 4. Bob and/or Charlie respond to Alice's message. In addition, they 277 might choose to update their key material which provides post- 278 compromise security Section 7.2.2. As a consequence of that 279 change, the group secrets are updated. 281 Clients may wish to do the following: 283 * create a group by inviting a set of other clients; 285 * add one or more clients to an existing group; 286 * remove one or more members from an existing group; 288 * update their own key material 290 * join an existing group; 292 * leave a group; 294 * send a message to everyone in the group; 296 * receive a message from someone in the group. 298 At the cryptographic level, clients (and by extension members in 299 groups) have equal permissions. For instance, any member can add or 300 remove another client in a group. This is in contrast to some 301 designs in which there is a single group controller who can modify 302 the group. MLS is compatible with having group administration 303 restricted to certain users, but we assume that those restrictions 304 are enforced by authentication and access control at the application 305 layer. 307 Thus, for instance, while the MLS protocol allows for any existing 308 member of a group to add a new client, applications which use MLS 309 might enforce additional restrictions for which only a subset of 310 members can qualify, and thus will handle enforcing group policies 311 (such as determining if a user is allowed to add new users to the 312 group) at the application level. 314 2.1. Group Members and Clients 316 While informally, a group can be considered to be a set of users 317 possibly using multiple endpoint devices to interact with the Service 318 Provider, this definition is too simplistic. 320 Formally, a client is a set of cryptographic objects composed of 321 public values such as a name (an identity), a public encryption key 322 and a public signature key. Ownership of a client by a user is 323 determined by the fact that the user has knowledge of the associated 324 secret values. When a client is part of a Group, it is called a 325 Member. In some messaging systems, clients belonging to the same 326 user must all share the same signature key pair, but MLS does not 327 assume this. 329 Users will often use multiple devices, e.g., a phone as well as a 330 laptop. Different devices may be represented as different clients, 331 with independent cryptographic state, or they may share cryptographic 332 state, relying on some application-provided mechanism to sync across 333 devices. 335 The formal definition of a Group in MLS is the set of clients that 336 have knowledge of the shared group secret established in the group 337 key establishment phase of the protocol and have contributed to it. 338 Until a Member has been added to the group and contributed to the 339 group secret in a manner verifiable by other members of the group, 340 other members cannot assume that the Member is a member of the group. 342 3. Authentication Service 344 The Authentication Service (AS) has to provide two functionalities: 346 1. Issue credentials to clients that attest to bindings between 347 identities and signature key pairs 349 2. Enable a group member to verify that a credential presented by 350 another member is valid 352 A member with a valid credential authenticates its MLS messages by 353 signing them with the private key corresponding to the public key in 354 its credential. 356 The AS is considered an abstract layer by the MLS specification, part 357 of this service could be, for instance, running on the members' 358 devices, while another part is a separate entity entirely. The 359 following examples illustrate the breadth of this concept: 361 * A PKI could be used as an AS [RFC5280]. The issuance function 362 would be provided by the certificate authorities in the PKI, and 363 the verification function would correspond to certificate 364 verification by clients. 366 * Several current messaging applications rely on users verifying 367 each others' key fingerprints for authentication. In this 368 scenario, the issuance function is simply the generation of a key 369 pair (i.e., credential is just an identifier and public key, with 370 no information to assist in verification). The verification 371 function is the application functionality that enables users to 372 verify keys. 374 * In a system based on Key Transparency (KT) [KeyTransparency], the 375 issuance function would correspond to the insertion of a key in a 376 KT log under a user's identity. The verification function would 377 correspond to verifying a key's inclusion in the log for a claimed 378 identity, together with the KT log's mechanisms for a user to 379 monitor and control which keys are associated to their identity. 381 By the nature of its roles in MLS authentication, the AS is invested 382 with a large amount of trust and the compromise of one of its 383 functionalities could allow an adversary to, among other things, 384 impersonate group members. We discuss security considerations 385 regarding the compromise of the different AS functionalities in 386 detail in Section 7.4.3. 388 The association between members' identities and signature keys is 389 fairly flexible in MLS. As noted above, there is no requirement that 390 all clients belonging to a given user use the same key pair (in fact, 391 such key reuse is forbidden to ensure clients have independent 392 cryptographic state). A member can also rotate the signature key 393 they use within a group. These mechanisms allow clients to use 394 different signature keys in different contexts and at different 395 points in time, providing unlinkability and post-compromise security 396 benefits. Some security trade-offs related to this flexibility are 397 discussed in the security considerations. 399 In many applications, there are multiple MLS clients that represent a 400 single entity, for example a human user with a mobile and desktop 401 version of an application. Often the same set of clients is 402 represented in exactly the same list of groups. In applications 403 where this is the intended situation, other clients can check that a 404 user is consistently represented by the same set of clients. This 405 would make it more difficult for a malicious AS to issue fake 406 credentials for a particular user because clients would expect the 407 credential to appear in all groups of which the user is a member. If 408 a client credential does not appear in all groups after some 409 relatively short period of time, clients have an indication that the 410 credential might have been created without the user's knowledge. Due 411 to the asynchronous nature of MLS, however, there may be transient 412 inconsistencies in a user's client set, so correlating users' clients 413 across groups is more of a detection mechanism than a prevention 414 mechanism. 416 4. Delivery Service 418 The Delivery Service (DS) is expected to play multiple roles in the 419 Service Provider architecture: 421 * Acting as a directory service providing the initial keying 422 material for clients to use. This allows a client to establish a 423 shared key and send encrypted messages to other clients even if 424 the other client is offline. 426 * Routing MLS messages among clients. 428 Depending on the level of trust given by the group to the Delivery 429 Service, the functional and privacy guarantees provided by MLS may 430 differ but the authentication and confidentiality guarantees remain 431 the same. 433 Unlike the Authentication Service which is trusted for authentication 434 and secrecy, the Delivery Service is completely untrusted regarding 435 this property. While privacy of group membership might be a problem 436 in the case of a Delivery Service server fanout, the Delivery Service 437 can be considered as an active, adaptive network attacker from the 438 point of view of the security analysis. 440 4.1. Key Storage 442 Upon joining the system, each client stores its initial cryptographic 443 key material with the Delivery Service. This key material, called a 444 KeyPackage, advertises the functional abilities of the client such as 445 supported protocol versions, supported extensions, and the following 446 cryptographic information: 448 * A credential from the Authentication Service attesting to the 449 binding between the identity and the client's signature key. 451 * The client's asymmetric encryption public key material. 453 All the parameters in the KeyPackage are signed with the signature 454 private key corresponding to the credential. 456 As noted above, users may own multiple clients, each with their own 457 keying material, and thus there may be multiple entries stored by 458 each user. 460 The Delivery Service is also responsible for allowing users to add, 461 remove or update their initial key material, and for ensuring that 462 the identifier for these keys are unique across all keys stored on 463 the Delivery Service. 465 4.2. Key Retrieval 467 When a client wishes to establish a group, it first contacts the 468 Delivery Service to request a KeyPackage for each other client, 469 authenticates the KeyPackages using the signature keys, and then can 470 use those to form the group. 472 4.3. Delivery of Messages 474 The main responsibility of the Delivery Service is to ensure delivery 475 of messages. Some MLS messages need only be delivered to some 476 members of a group (e.g., the message initializing a new member's 477 state), while others need to be delivered to all members. The 478 Delivery Service may enable these delivery patterns via unicast 479 channels (sometimes known as "client fanout"), broadcast channels 480 ("server fanout"), or a mix of both. 482 For the most part, MLS does not require the Delivery Service to 483 deliver messages in any particular order. The one requirement is 484 that because an MLS group has a linear history, the members of the 485 group must agree on the order in which changes are applied. 486 Concretely, the group must agree on which MLS Commit messages to 487 apply. There are a variety of ways to achieve this agreement, but 488 most of them rely on some help from the Delivery Service. For 489 example, if a Delivery Service provides delivery in the same order to 490 all group members, then the members can simply apply Commits in the 491 order in which they appear. 493 Each Commit is premised on a given state or "epoch" of the group. 494 The Delivery Service must transmit to the group exactly one Commit 495 message per epoch. 497 Much like the Authentication Service, the Delivery Service can be 498 split between server and client components. Achieving the required 499 uniqueness property will typically require a combination of client 500 and server behaviors. For example, all of the following examples 501 provide a unique Commit per epoch: 503 * A "filtering server" Delivery Service where a server rejects all 504 but the first Commit for an epoch and clients apply each Commit 505 they receive. 507 * An "ordering server" Delivery Service where a server forwards all 508 messages but assures that all clients see Commits in the same 509 order, and clients. 511 * A "passive server" Delivery Service where a server forwards all 512 messages without ordering or reliability guarantees, and clients 513 execute some secondary consensus protocol to choose among the 514 Commits received in a window. 516 The MLS protocol provides three important pieces of information 517 within an MLSCiphertext message in order to provide ordering: 519 * The Group Identifier (group ID) to allow for distinguishing the 520 group for which the message has been sent; 522 * The Epoch number, which represents the number of changes (version) 523 of the group associated with a specific group ID, and allows for 524 lexicographical ordering of messages from different epochs within 525 the same group; 527 * The Content Type of the message, which allows the Delivery Service 528 to determine the ordering requirement on the message, in 529 particular distinguishing Commit messages from other messages. 531 The MLS protocol itself can verify these properties. For instance, 532 if the Delivery Service reorders messages from a client or provides 533 different clients with inconsistent orderings, then clients can put 534 messages back in their proper order. The asynchronous nature of MLS 535 means that within an epoch, messages are only ordered per-sender, not 536 globally. 538 Note that some forms of Delivery Service misbehavior are still 539 possible and difficult to detect. For instance, a Delivery Service 540 can simply refuse to relay messages to and from a given client. 541 Without some sort of side information, other clients cannot generally 542 distinguish this form of Denial of Service (DoS) attack. 544 4.4. Membership knowledge 546 Group membership is itself sensitive information and MLS is designed 547 to limit the amount of persistent metadata. However, large groups 548 often require an infrastructure which provides server fanout. In the 549 case of client fanout, the destination of a message is known by all 550 clients, hence the server usually does not need this information. 551 However, they may learn this information through traffic analysis. 552 Unfortunately, in a server-side fanout model, the Delivery Service 553 can learn that a given client is sending the same message to a set of 554 other clients. In addition, there may be applications of MLS in 555 which the group membership list is stored on some server associated 556 with the Delivery Service. 558 While this knowledge is not a breach of the protocol's authentication 559 or confidentiality guarantees, it is a serious issue for privacy. In 560 the case where metadata has to be persisted for functionality, it 561 SHOULD be stored encrypted at rest. Applications should also 562 consider anonymous systems for server fanout such as Loopix [Loopix]. 564 4.5. Membership and offline members 566 Because Forward Secrecy (FS) and Post-Compromise Security (PCS) rely 567 on the active deletion and replacement of keying material, any client 568 which is persistently offline may still be holding old keying 569 material and thus be a threat to both FS and PCS if it is later 570 compromised. 572 MLS cannot inherently defend against this problem, especially in the 573 case where the client has not processed messages, but MLS-using 574 systems can enforce some mechanism to try to retain these properties. 575 Typically this will consist of evicting clients which are idle for 576 too long, or mandating a key update from clients that are not 577 otherwise sending messages. The precise details of such mechanisms 578 are a matter of local policy and beyond the scope of this document. 580 5. Functional Requirements 582 MLS is designed as a large-scale group messaging protocol and hence 583 aims to provide both performance and safety to its users. Messaging 584 systems that implement MLS provide support for conversations 585 involving two or more members, and aim to scale to groups with tens 586 of thousands of members, typically including many users using 587 multiple devices. 589 5.1. Membership Changes 591 MLS aims to provide agreement on group membership, meaning that all 592 group members have agreed on the list of current group members. 594 Some applications may wish to enforce ACLs to limit addition or 595 removal of group members, to privileged clients or users. Others may 596 wish to require authorization from the current group members or a 597 subset thereof. Such policies can be implemented at the application 598 layer, on top of MLS. Regardless, MLS does not allow for or support 599 addition or removal of group members without informing all other 600 members. 602 Membership of an MLS group is managed at the level of individual 603 clients. In most cases, a client corresponds to a specific device 604 used by a user. If a user has multiple devices, the user will be 605 represented in a group by multiple clients. If an application wishes 606 to implement operations at the level of users, it is up to the 607 application to track which clients belong to a given user and ensure 608 that they are added / removed consistently. 610 MLS provides two mechanisms for changing the membership of a group. 611 The primary mechanism is for an authorized member of the group to 612 send a Commit that adds or removes other members. The second 613 mechanism is an "external join": A member of the group publishes 614 certain information about the group, which a new member can use to 615 construct an "external" Commit message that adds the new member to 616 the group. (There is no similarly unilateral way for a member to 617 leave the group; they must be removed by a remaining member.) 619 With both mechanisms, changes to the membership are initiated from 620 inside the group. When members perform changes directly, this is 621 clearly the case. External joins are authorized indirectly, in the 622 sense that a member publishing a GroupInfo object authorizes anyone 623 to join who has access to the GroupInfo object. External joins do 624 not allow for more granular authorization checks to be done before 625 the new member is added to the group, so if an application wishes to 626 both allow external joins and enforce such checks, then the 627 application will need to do such checks when a member joins, and 628 remove them if checks fail. 630 Application setup may also determine other criteria for membership 631 validity. For example, per-device signature keys can be signed by an 632 identity key recognized by other participants. If a certificate 633 chain is used to sign off on device signature keys, then revocation 634 by the owner adds an alternative flag to prompt membership removal. 636 An MLS group's secrets change on every change of membership, so each 637 client only has access to the secrets used by the group while they 638 are a member. Messages sent before a client joins or after they are 639 removed are protected with keys that are not accessible to the 640 client. Compromise of a member removed from a group does not affect 641 the security of messages sent after their removal. Messages sent 642 during the client's membership are also secure as long as the client 643 has properly implemented the MLS deletion schedule. 645 5.2. Parallel Groups 647 Any user or client may have membership in several groups 648 simultaneously. The set of members of any group may or may not form 649 a subset of the members of another group. MLS guarantees that the FS 650 and PCS goals within a given group are maintained and not weakened by 651 user membership in multiple groups. However, actions in other groups 652 likewise do not strengthen the FS and PCS guarantees within a given 653 group, e.g. key updates within a given group following a device 654 compromise does not provide PCS healing in other groups; each group 655 must be updated separately to achieve internal goals. This also 656 applies to future groups that a member has yet to join, that are 657 likewise unaffected by updates performed in current groups. 659 Applications may strengthen connectivity among parallel groups by 660 requiring periodic key updates from a user across all groups in which 661 they have membership. 663 Applications may use the PSK mechanism to link healing properties 664 among parallel groups. For example, suppose a common member M of two 665 groups A and B has performed a key update in group A but not in group 666 B. The key update provides PCS with regard to M in group A. If a 667 PSK is exported from group A and injected into group B, then some of 668 these PCS properties carry over to group B, since the PSK and secrets 669 derived from it are only known to the new, updated version of M, not 670 to the old, possibly compromised version of M. 672 5.3. Asynchronous Usage 674 No operation in MLS requires two distinct clients or members to be 675 online simultaneously. In particular, members participating in 676 conversations protected using MLS can update the group's keys, add or 677 remove new members, and send messages without waiting for another 678 user's reply. 680 Messaging systems that implement MLS have to provide a transport 681 layer for delivering messages asynchronously and reliably. 683 5.4. Access Control 685 The MLS protocol allows each member of the messaging group to perform 686 operations equally. This is because all clients within a group 687 (members) have access to the shared cryptographic material. However 688 every service/infrastructure has control over policies applied to its 689 own clients. Applications managing MLS clients can be configured to 690 allow for specific group operations. On the one hand, an application 691 could decide that a group administrator will be the only member to 692 perform add and remove operations. On the other hand, in many 693 settings such as open discussion forums, joining can be allowed for 694 anyone. 696 The MLS protocol can, in certain modes, exchange unencrypted group 697 operation messages. This flexibility is to allow services to perform 698 access control tasks on behalf of the group. 700 While the Application messages will always be encrypted, having the 701 handshake messages in plaintext has inconveniences in terms of 702 privacy as someone could collect the signatures on the handshake 703 messages and use them for tracking. 705 *RECOMMENDATION:* Prefer using encrypted group operation messages 706 to avoid privacy issues related to non-encrypted signatures. 708 Note that in the default case of encrypted handshake messages, any 709 access control policies will be applied at the client, so the 710 application must ensure that the access control policies are 711 consistent across all clients to make sure that they remain in sync. 712 If two different policies were applied, the clients might not accept 713 or reject a group operation and end-up in different cryptographic 714 states, breaking their ability to communicate. 716 *RECOMMENDATION:* Avoid using inconsistent access control policies 717 in the case of encrypted group operations. 719 MLS allows actors outside the group to influence the group in two 720 ways: External signers can submit proposals for changes to the group, 721 and new joiners can use an external join to add themselves to the 722 group. The external_senders extension ensures that all members agree 723 on which signers are allowed to send proposals, but any other 724 policies must be assured to be consistent as above. 726 ** RECOMMENDATION:** Have an explicit group policy setting the 727 conditions under which external joins are allowed. 729 5.5. Recovery After State Loss 731 Group members whose local MLS state is lost or corrupted can 732 reinitialize their state by re-joining the group as a new member and 733 removing the member representing their earlier state. An application 734 can require that a client performing such a reinitialization prove 735 its prior membership with a PSK. 737 There are a few practical challenges to this approach. For example, 738 the application will need to ensure that all members have the 739 required PSK, including any new members that have joined the group 740 since the epoch in which the PSK was issued. 742 Reinitializing in this way does not provide the member with access to 743 group messages from during the state loss window, but enables proof 744 of prior membership in the group. Applications may choose various 745 configurations for providing lost messages to valid group members 746 that are able to prove prior membership. 748 5.6. Support for Multiple Devices 750 It is typically expected for users within a group to own various 751 devices. A new device can be added to a group and be considered as a 752 new client by the protocol. This client will not gain access to the 753 history even if it is owned by someone who owns another member of the 754 group. Restoring history is typically not allowed at the protocol 755 level but applications can elect to provide such a mechanism outside 756 of MLS. Such mechanisms, if used, may reduce the FS and PCS 757 guarantees provided by MLS. 759 5.7. Extensibility 761 The MLS protocol provides several extension points where additional 762 information can be provided. Extensions to KeyPackages allow clients 763 to disclose additional information about their capabilities. Groups 764 can also have extension data associated with them, and the group 765 agreement properties of MLS will confirm that all members of the 766 group agree on the content of these extensions. 768 5.8. Application Data Framing and Negotiation 770 Application messages carried by MLS are opaque to the protocol; they 771 can contain arbitrary data. Each application which uses MLS needs to 772 define the format of its application_data and any mechanism necessary 773 to negotiate the format of that content over the lifetime of an MLS 774 group. In many applications this means managing format migrations 775 for groups with multiple members who may each be offline at 776 unpredictable times. 778 *RECOMMENDATION:* Use the default content mechanism defined in 779 [I-D.mahy-mls-content-neg], unless the specific application 780 defines another mechanism which more appropriately addresses the 781 same requirements for that application of MLS. 783 The MLS framing for application messages also provides a field where 784 clients can send information that is authenticated but not encrypted. 785 Such information can be used by servers that handle the message, but 786 group members are assured that it has not been tampered with. 788 5.9. Federation 790 The protocol aims to be compatible with federated environments. 791 While this document does not specify all necessary mechanisms 792 required for federation, multiple MLS implementations can 793 interoperate to form federated systems if they use compatible 794 authentication mechanisms, ciphersuites, and infrastructure 795 functionalities. 797 5.10. Compatibility with Future Versions of MLS 799 It is important that multiple versions of MLS be able to coexist in 800 the future. Thus, MLS offers a version negotiation mechanism; this 801 mechanism prevents version downgrade attacks where an attacker would 802 actively rewrite messages with a lower protocol version than the ones 803 originally offered by the endpoints. When multiple versions of MLS 804 are available, the negotiation protocol guarantees that the version 805 agreed upon will be the highest version supported in common by the 806 group. 808 In MLS 1.0, the creator of the group is responsible for selecting the 809 best ciphersuite supported across clients. Each client is able to 810 verify availability of protocol version, ciphersuites and extensions 811 at all times once he has at least received the first group operation 812 message. 814 Each member of an MLS group advertises the protocol functionality 815 they support. These capability advertisements can be updated over 816 time, e.g., if client software is updated while the client is a 817 member of a group. Thus, in addition to preventing downgrade 818 attacks, the members of a group can also observe when it is safe to 819 upgrade to a new ciphersuite or protocol version. 821 6. Operational Requirements 823 MLS is a security layer that needs to be integrated with an 824 application. A fully-functional deployment of MLS will have to make 825 a number of decisions about how MLS is configured and operated. 826 Deployments that wish to interoperate will need to make compatible 827 decisions. This section lists all of the dependencies of an MLS 828 deployment that are external to the protocol specification, but would 829 still need to be aligned within a given MLS deployment, or for two 830 deployments to potentially interoperate. 832 The protocol has a built-in ability to negotiate protocol versions, 833 ciphersuites, extensions, credential types, and additional proposal 834 types. For two deployments to interoperate, they must have 835 overlapping support in each of these categories. A 836 required_capabilities extension can help maintain interoperability 837 with a wider set of clients by ensuring that certain functionality 838 continues to be supported by a group, even if the clients in the 839 group aren't currently relying on it. 841 MLS relies on the following network services. These network services 842 would need to be compatible in order for two different deployments 843 based on them to interoperate. 845 * An *Authentication Service*, described fully in Section 3, defines 846 the types of credentials which may be used in a deployment and 847 provides methods for: 849 1. Issuing new credentials, 851 2. Validating a credential against a reference identifier, and 853 3. Validating whether or not two credentials represent the same 854 user. 856 * A *Delivery Service*, described fully in Section 4, provides 857 methods for: 859 1. Delivering messages sent to a group to all members in the 860 group. 862 2. Delivering Welcome messages to new members of a group. 864 3. Downloading KeyPackages for specific clients, and uploading 865 new KeyPackages for a user's own clients. 867 * Additional services may or may not be required depending on the 868 application design: 870 - If assisted joining is desired (meaning that the ratchet tree 871 is not provided in Welcome messages), there must be a method to 872 download the ratchet tree corresponding to a group. 874 - If assisted joining is desired and the Delivery Service is not 875 able to compute the ratchet tree itself (because some proposals 876 or commits are sent encrypted), there must be a method for 877 group members to publish the updated ratchet tree after each 878 commit. 880 - If external joiners are allowed, there must be a method to 881 publish a serialized GroupInfo object (with an external_pub 882 extension) that corresponds to a specific group and epoch, and 883 keep that object in sync with the state of the group. 885 - If an application chooses not to allow assisted or external 886 joining, it may instead provide a method for external users to 887 solicit group members (or a designated service) to add them to 888 a group. 890 - If the application uses external PSKs, or uses resumption PSKs 891 that all members of a group may not have access to, there must 892 be a method for distributing these PSKs to group members. 894 - If an application wishes to detect and possibly discipline 895 members that send malformed commits with the intention of 896 corrupting a group's state, there must be a method for 897 reporting and validating malformed commits. 899 MLS requires the following parameters to be defined, which must be 900 the same for two implementations to interoperate: 902 * The maximum total lifetime that is acceptable for a KeyPackage. 904 * How long to store the resumption secret for past epochs of a 905 group. 907 * The degree of tolerance that's allowed for out-of-order message 908 delivery: 910 - How long to keep unused nonce and key pairs for a sender 912 - A maximum number of unused key pairs to keep. 914 - A maximum number of steps that clients will move a secret tree 915 ratchet forward in response to a single message before 916 rejecting it. 918 MLS provides the following locations where an application may store 919 arbitrary data. The format and intention of any data in these 920 locations must align for two deployments to interoperate: 922 * Application data, sent as the payload of an encrypted message. 924 * Additional authenticated data, sent unencrypted in an otherwise 925 encrypted message. 927 * Group IDs, as decided by group creators and used to uniquely 928 identify a group. 930 * The application_id extension of a LeafNode. 932 MLS requires the following policies to be defined, which restrict the 933 set of acceptable behavior in a group. These policies must be 934 consistent between deployments for them to interoperate: 936 * A policy on when to send proposals and commits in plaintext 937 instead of encrypted. 939 * A policy for which proposals are valid to have in a commit, 940 including but not limited to: 942 - When a member is allowed to add or remove other members of the 943 group. 945 - When, and under what circumstances, a reinitialization proposal 946 is allowed. 948 - When proposals from external senders are allowed. 950 - When external joiners are allowed. 952 * A policy for when two credentials represent the same client. Note 953 that many credentials may be issued authenticating the same 954 identity but for different signature keys, because each credential 955 corresponds to a different device (client) owned by the same 956 application user. However, one device may control many signature 957 keys but should still only be considered a single client. 959 * A policy on how long to allow a member to stay in a group without 960 updating its leaf keys before removing them. 962 Finally, there are some additional application-defined behaviors that 963 are partially an individual application's decision but may overlap 964 with interoperability: 966 * If there's any policy on how or when to pad messages. 968 * If there is any policy for when to send a reinitialization 969 proposal. 971 * How often clients should update their leaf keys. 973 * Whether to prefer sending full commits or partial/empty commits. 975 * Whether there should be a required_capabilities extension in 976 groups. 978 7. Security and Privacy Considerations 980 MLS adopts the Internet threat model [RFC3552] and therefore assumes 981 that the attacker has complete control of the network. It is 982 intended to provide the security services described in the face of 983 such attackers. 985 * The attacker can monitor the entire network. 987 * The attacker can read unprotected messages. 989 * The attacker can generate, inject and delete any message in the 990 unprotected transport layer. 992 In addition, these guarantees are intended to degrade gracefully in 993 the presence of compromise of the transport security links as well as 994 of both clients and elements of the messaging system, as described in 995 the remainder of this section. 997 Generally, MLS is designed under the assumption that the transport 998 layer is present to protect metadata and privacy in general, while 999 the MLS protocol is providing stronger guarantees such as 1000 confidentiality, integrity and authentication guarantees. Stronger 1001 properties such as deniability can also be achieved in specific 1002 architecture designs. 1004 7.1. Assumptions on Transport Security Links 1006 Any secure channel can be used as a transport layer to protect MLS 1007 messages such as QUIC, TLS, WireGuard or TOR. However, the MLS 1008 protocol is designed to consider the following threat-model: 1010 * The attacker can read, write, and delete arbitrary messages inside 1011 the secure transport channel. 1013 This departs from most threat models where we consider that the 1014 secure channel used for transport always provides secrecy. The 1015 reason for this consideration is that in the group setting, active 1016 malicious insiders or adversarial services are to be considered. 1018 7.1.1. Metadata Protection for Unencrypted Group Operations 1020 The main use of the secure transport layer for MLS is to protect the 1021 already limited amount of metadata. Very little information is 1022 contained in the unencrypted header of the MLS protocol message 1023 format for group operation messages, and application messages are 1024 always encrypted in MLS. 1026 MLS avoids needing to send the full list of recipients to the server 1027 for dispatching messages because that list is potentially extremely 1028 large in MLS. Therefore, the metadata typically consists of a 1029 pseudo-random Group Identifier (GID), a numerical value to determine 1030 the epoch of the group (the number of changes that have been made to 1031 the group), and another numerical value referring to the specific key 1032 needed to decrypt the ciphertext content. 1034 The MLS protocol provides an authenticated "Additional Authenticated 1035 Data" field for applications to make data available outside the 1036 MLSCiphertext. 1038 *RECOMMENDATION:* Use the "Additional Authenticated Data" field of 1039 the MLSCiphertext message instead of using other unauthenticated 1040 means of sending metadata throughout the infrastructure. If the 1041 data is private, the infrastructure should use encrypted 1042 Application messages instead. 1044 Even though some of this metadata information does not consist of 1045 secret payloads, in correlation with other data a network observer 1046 might be able to reconstruct sensitive information. Using a secure 1047 channel to transfer this information will prevent a network attacker 1048 from accessing this MLS protocol metadata if it cannot compromise the 1049 secure channel. 1051 More importantly, there is one specific case where having no secure 1052 channel to exchange the MLS messages can have a serious impact on 1053 privacy. In the case of unencrypted group operation messages, 1054 observing the signatures of the group operation messages may lead an 1055 adversary to extract information about the group memberships. 1057 *RECOMMENDATION:* Never use the unencrypted mode for group 1058 operations without using a secure channel for the transport layer. 1060 7.1.2. DoS protection 1062 In general we do not consider Denial of Service (DoS) resistance to 1063 be the responsibility of the protocol. However, it should not be 1064 possible for anyone aside from the Delivery Service to perform a 1065 trivial DoS attack from which it is hard to recover. This can be 1066 achieved through the secure transport layer. 1068 In the centralized setting, DoS protection can typically be performed 1069 by using tickets or cookies which identify users to a service for a 1070 certain number of connections. Such a system helps in preventing 1071 anonymous clients from sending arbitrary numbers of group operation 1072 messages to the Delivery Service or the MLS clients. 1074 *RECOMMENDATION:* Anonymous credentials can be used in order to 1075 help DoS attacks prevention, in a privacy preserving manner. Note 1076 that the privacy of these mechanisms has to be adjusted in 1077 accordance with the privacy expected from the secure transport 1078 links. (See more discussion further down.) 1080 7.1.3. Message Suppression and Error Correction 1082 As noted above, MLS is designed to provide some robustness in the 1083 face of tampering within the secure transport, i.e., tampering by the 1084 Delivery Service. The confidentiality and authenticity properties of 1085 MLS prevent the DS reading or writing messages. MLS also provides a 1086 few tools for detecting message suppression, with the caveat that 1087 message suppression cannot always be distinguished from transport 1088 failure. 1090 Each encrypted MLS message carries a "generation" number which is a 1091 per-sender incrementing counter. If a group member observes a gap in 1092 the generation sequence for a sender, then they know that they have 1093 missed a message from that sender. MLS also provides a facility for 1094 group members to send authenticated acknowledgements of application 1095 messages received within a group. 1097 As discussed in Section 4, the Delivery Service is trusted to select 1098 the single Commit message that is applied in each epoch from among 1099 the ones sent by group members. Since only one Commit per epoch is 1100 meaningful, it's not useful for the DS to transmit multiple Commits 1101 to clients. The risk remains that the DS will use the ability 1102 maliciously. 1104 While it is difficult or impossible to prevent a network adversary 1105 from suppressing payloads in transit, in certain infrastructures such 1106 as banks or governments settings, unidirectional transports can be 1107 used and be enforced via electronic or physical devices such as 1108 diodes. This can lead to payload corruption which does not affect 1109 the security or privacy properties of the MLS protocol but does 1110 affect the reliability of the service. In that case specific 1111 measures can be taken to ensure the appropriate level of redundancy 1112 and quality of service for MLS. 1114 *RECOMMENDATION:* If unidirectional transport is used for the 1115 secure transport channel, prefer using a protocol which provides 1116 Forward Error Correction. 1118 7.2. Intended Security Guarantees 1120 MLS aims to provide a number of security guarantees, covering 1121 authentication, as well as confidentiality guarantees to different 1122 degrees in different scenarios. 1124 7.2.1. Message Secrecy and Authentication 1126 MLS enforces the encryption of application messages and thus 1127 generally guarantees authentication and confidentiality of 1128 application messages sent in a group. 1130 In particular, this means that only other members of a given group 1131 can decrypt the payload of a given application message, which 1132 includes information about the sender of the message. 1134 Similarly, group members receiving a message from another group 1135 member can authenticate that group member as the sender of the 1136 message and verify the message's integrity. 1138 Message content can be deniable if the signature keys are exchanged 1139 over a deniable channel prior to signing messages. 1141 Depending on the group settings, handshake messages can be encrypted 1142 as well. If that is the case, the same security guarantees apply. 1144 MLS optionally allows the addition of padding to messages, mitigating 1145 the amount of information leaked about the length of the plaintext to 1146 an observer on the network. 1148 7.2.2. Forward and Post-Compromise Security 1150 MLS provides additional protection regarding secrecy of past messages 1151 and future messages. These cryptographic security properties are 1152 Forward Secrecy (FS) and Post-Compromise Security (PCS). 1154 FS means that access to all encrypted traffic history combined with 1155 an access to all current keying material on clients will not defeat 1156 the secrecy properties of messages older than the oldest key of the 1157 compromised client. Note that this means that clients have the 1158 extremely important role of deleting appropriate keys as soon as they 1159 have been used with the expected message, otherwise the secrecy of 1160 the messages and the security for MLS is considerably weakened. 1162 PCS means that if a group member's state is compromised at some time 1163 t but the group member subsequently performs an update at some time 1164 t', then all MLS guarantees apply to messages sent by the member 1165 after time t', and by other members after they have processed the 1166 update. For example, if an attacker learns all secrets known to 1167 Alice at time t, including both Alice's long-term secret keys and all 1168 shared group keys, but Alice performs a key update at time t', then 1169 the attacker is unable to violate any of the MLS security properties 1170 after the updates have been processed. 1172 Both of these properties are satisfied even against compromised DSs 1173 and ASs. 1175 7.2.3. Non-Repudiation vs Deniability 1177 MLS provides strong authentication within a group, such that a group 1178 member cannot send a message that appears to be from another group 1179 member. Additionally, some services require that a recipient be able 1180 to prove to the service provider that a message was sent by a given 1181 client, in order to report abuse. MLS supports both of these use 1182 cases. In some deployments, these services are provided by 1183 mechanisms which allow the receiver to prove a message's origin to a 1184 third party. This is often called "non-repudiation". 1186 Roughly speaking, "deniability" is the opposite of "non-repudiation", 1187 i.e., the property that it is impossible to prove to a third party 1188 that a message was sent by a given sender. MLS does not make any 1189 claims with regard to deniability. It may be possible to operate MLS 1190 in ways that provide certain deniability properties, but defining the 1191 specific requirements and resulting notions of deniability requires 1192 further analysis. 1194 7.3. Endpoint Compromise 1196 The MLS protocol adopts a threat model which includes multiple forms 1197 of endpoint/client compromise. While adversaries are in a very 1198 strong position if they have compromised an MLS client, there are 1199 still situations where security guarantees can be recovered thanks to 1200 the PCS properties achieved by the MLS protocol. 1202 In this section we will explore the consequences and recommendations 1203 regarding the following compromise scenarios: 1205 * The attacker has access to a specific symmetric encryption key 1207 * The attacker has access to the group secrets for one group 1209 * The attacker has access to a signature oracle for any group 1211 * The attacker has access to the signature key for one group 1213 * The attacker has access to all secrets of a user for all groups 1214 (full state compromise) 1216 Recall that the MLS protocol provides chains of AEAD keys, per sender 1217 that are generated from Group Secrets. These keys are used to 1218 protect MLS Plaintext messages which can be Group Operation or 1219 Application messages. The Group Operation messages offer an 1220 additional protection as the secret exchanged within the TreeKEM 1221 group key agreement are public-key encrypted to subgroups with HPKE. 1223 7.3.1. Compromise of AEAD key material 1225 In some circumstances, adversaries may have access to specific AEAD 1226 keys and nonces which protect an Application or a Group Operation 1227 message. While this is a very weak kind of compromise, it can be 1228 realistic in cases of implementation vulnerabilities where only part 1229 of the memory leaks to the adversary. 1231 When an AEAD key is compromised, the adversary has access to a set of 1232 AEAD keys for the same chain and the same epoch, hence can decrypt 1233 messages sent using keys of this chain. An adversary cannot send a 1234 message to a group which appears to be from any valid client since 1235 they cannot forge the signature. 1237 The MLS protocol will ensure that an adversary cannot compute any 1238 previous AEAD keys for the same epoch, or any other epochs. Because 1239 of its Forward Secrecy guarantees, MLS will also retain secrecy of 1240 all other AEAD keys generated for _other_ MLS clients, outside this 1241 dedicated chain of AEAD keys and nonces, even within the epoch of the 1242 compromise. However the MLS protocol does not provide Post 1243 Compromise Secrecy for AEAD encryption within an epoch. This means 1244 that if the AEAD key of a chain is compromised, the adversary can 1245 compute an arbitrary number of subsequent AEAD keys for that chain. 1247 These guarantees are ensured by the structure of the MLS key schedule 1248 which provides Forward Secrecy for these AEAD encryptions, across the 1249 messages within the epoch and also across previous epochs. Those 1250 chains are completely disjoint and compromising keys across the 1251 chains would mean that some Group Secrets have been compromised, 1252 which is not the case in this attack scenario (we explore stronger 1253 compromise scenarios as part of the following sections). 1255 MLS provides Post-Compromise Secrecy against an active adaptive 1256 attacker across epochs for AEAD encryption, which means that as soon 1257 as the epoch is changed, if the attacker does not have access to more 1258 secret material they won't be able to access any protected messages 1259 from future epochs. 1261 In the case of an Application message, an AEAD key compromise means 1262 that the encrypted application message will be leaked as well as the 1263 signature over that message. This means that the compromise has both 1264 confidentiality and privacy implications on the future AEAD 1265 encryptions of that chain. In the case of a Group Operation message, 1266 only the privacy is affected, as the signature is revealed, because 1267 the secrets themselves are protected by HPKE encryption. 1269 Note that under that compromise scenario, authentication is not 1270 affected in neither of these cases. As every member of the group can 1271 compute the AEAD keys for all the chains (they have access to the 1272 Group Secrets) in order to send and receive messages, the 1273 authentication provided by the AEAD encryption layer of the common 1274 framing mechanism is very weak. Successful decryption of an AEAD 1275 encrypted message only guarantees that a member of the group sent the 1276 message. 1278 7.3.2. Compromise of the Group Secrets of a single group for one or 1279 more group epochs 1281 The attack scenario considering an adversary gaining access to a set 1282 of Group secrets is significantly stronger. This can typically be 1283 the case when a member of the group is compromised. For this 1284 scenario, we consider that the signature keys are not compromised. 1285 This can be the case for instance if the adversary has access to part 1286 of the memory containing the group secrets but not to the signature 1287 keys which might be stored in a secure enclave. 1289 In this scenario, the adversary gains the ability to compute any 1290 number of AEAD encryption keys for any AEAD chains and can encrypt 1291 and decrypt all messages for the compromised epochs. 1293 If the adversary is passive, it is expected from the PCS properties 1294 of the MLS protocol that, as soon as an honest Commit message is sent 1295 by the compromised party, the next epochs will provide message 1296 secrecy. 1298 If the adversary is active, the adversary can follow the protocol and 1299 perform updates on behalf of the compromised party with no ability to 1300 an honest group to recover message secrecy. However, MLS provides 1301 PCS against active adaptive attackers through its Remove group 1302 operation. This means that, as long as other members of the group 1303 are honest, the protocol will guarantee message secrecy for all 1304 messages exchanged in the epochs after the compromised party has been 1305 removed. 1307 7.3.3. Compromise by an active adversary with the ability to sign 1308 messages 1310 Under such a scenario, where an active adversary has compromised an 1311 MLS client, two different settings emerge. In the strongest 1312 compromise scenario, the attacker has access to the signing key and 1313 can forge authenticated messages. In a weaker, yet realistic 1314 scenario, the attacker has compromised a client but the client 1315 signature keys are protected with dedicated hardware features which 1316 do not allow direct access to the value of the private key and 1317 instead provide a signature API. 1319 When considering an active adaptive attacker with access to a 1320 signature oracle, the compromise scenario implies a significant 1321 impact on both the secrecy and authentication guarantees of the 1322 protocol, especially if the attacker also has access to the group 1323 secrets. In that case both secrecy and authentication are broken. 1324 The attacker can generate any message, for the current and future 1325 epochs until an honest update from the compromised client happens. 1327 Note that under this compromise scenario, the attacker can perform 1328 all operations which are available to an legitimate client even 1329 without access to the actual value of the signature key. 1331 Without access to the group secrets, the adversary will not have the 1332 ability to generate messages which look valid to other members of the 1333 group and to the infrastructure as they need to have access to group 1334 secrets to compute the encryption keys or the membership tag. 1336 7.3.4. Compromise of the authentication with access to a signature key 1338 The difference between having access to the value of the signature 1339 key and only having access to a signing oracle is not about the 1340 ability of an active adaptive network attacker to perform different 1341 operations during the time of the compromise, the attacker can 1342 perform every operation available to a legitimate client in both 1343 cases. 1345 There is a significant difference, however in terms of recovery after 1346 a compromise. 1348 Because of the PCS guarantees provided by the MLS protocol, when a 1349 previously compromised client performs an honest Commit which is not 1350 under the control of the adversary, both secrecy and authentication 1351 of messages can be recovered in the case where the attacker didn't 1352 get access to the key. Because the adversary doesn't have the key 1353 and has lost the ability to sign messages, they cannot authenticate 1354 messages on behalf of the compromised party, even if they still have 1355 control over some group keys by colluding with other members of the 1356 group. 1358 This is in contrast with the case where the signature key is leaked. 1359 In that case PCS of the MLS protocol will eventually allow recovery 1360 of the authentication of messages for future epochs but only after 1361 compromised parties refresh their credentials securely. 1363 Beware that in both oracle and private key access, an active adaptive 1364 attacker, can follow the protocol and request to update its own 1365 credential. This in turn induces a signature key rotation which 1366 could provide the attacker with part or the full value of the private 1367 key depending on the architecture of the service provider. 1369 *RECOMMENDATION:* Signature private keys should be 1370 compartmentalized from other secrets and preferably protected by 1371 an HSM or dedicated hardware features to allow recovery of the 1372 authentication for future messages after a compromise. 1374 7.3.5. Security consideration in the context of a full state compromise 1376 In real-world compromise scenarios, it is often the case that 1377 adversaries target specific devices to obtain parts of the memory or 1378 even the ability to execute arbitrary code in the targeted device. 1380 Also, recall that in this setting, the application will often retain 1381 the unencrypted messages. If so, the adversary does not have to 1382 break encryption at all to access sent and received messages. 1383 Messages may also be sent by using the application to instruct the 1384 protocol implementation. 1386 *RECOMMENDATION:* If messages are stored on the device, they 1387 should be protected using encryption at rest, and the keys used 1388 should be stored securely using dedicated mechanisms on the 1389 device. 1391 *RECOMMENDATION:* If the threat model of the system is against an 1392 adversary which can access the messages on the device without even 1393 needing to attack MLS, the application should delete plaintext 1394 messages and ciphertexts immediately after encryption or 1395 decryption. 1397 Even though, from the strict point of view of the security 1398 formalization, a ciphertext is always public and will forever be, 1399 there is no loss in trying to erase ciphertexts as much as possible. 1401 Note that this document makes a clear distinction between the way 1402 signature keys and other group shared secrets must be handled. In 1403 particular, a large set of group secrets cannot necessarily be 1404 assumed to be protected by an HSM or secure enclave features. This 1405 is especially true because these keys are extremely frequently used 1406 and changed with each message received by a client. 1408 However, the signature private keys are mostly used by clients to 1409 send a message. They also are providing the strong authentication 1410 guarantees to other clients, hence we consider that their protection 1411 by additional security mechanism should be a priority. 1413 Overall there is no way to detect or prevent these compromise, as 1414 discussed in the previous sections, performing separation of the 1415 application secret states can help recovery after compromise, this is 1416 the case for signature keys but similar concern exists for the 1417 encryption private key used in the TreeKEM Group Key Agreement. 1419 *RECOMMENDATION:* The secret keys used for public key encryption 1420 should be stored similarly to the way the signature keys are 1421 stored, as keys can be used to decrypt the group operation 1422 messages and contain the secret material used to compute all the 1423 group secrets. 1425 Even if secure enclaves are not perfectly secure, or even completely 1426 broken, adopting additional protections for these keys can ease 1427 recovery of the secrecy and authentication guarantees after a 1428 compromise where, for instance, an attacker can sign messages without 1429 having access to the key. In certain contexts, the rotation of 1430 credentials might only be triggered by the AS through ACLs, hence be 1431 outside of the capabilities of the attacker. 1433 7.4. Service Node Compromise 1435 7.4.1. General considerations 1437 7.4.1.1. Privacy of the network connections 1439 There are many scenarios leading to communication between the 1440 application on a device and the Delivery Service or the 1441 Authentication Service. In particular when: 1443 * The application connects to the Authentication Service to generate 1444 or validate a new credential before distributing it. 1446 * The application fetches credentials at the Delivery Service prior 1447 to creating a messaging group (one-to-one or more than two 1448 clients). 1450 * The application fetches service provider information or messages 1451 on the Delivery Service. 1453 * The application sends service provider information or messages to 1454 the Delivery Service. 1456 In all these cases, the application will often connect to the device 1457 via a secure transport which leaks information about the origin of 1458 the request such as the IP address and depending on the protocol the 1459 MAC address of the device. 1461 Similar concerns exist in the peer-to-peer use cases of MLS. 1463 *RECOMMENDATION:* In the case where privacy or anonymity is 1464 important, using adequate protection such as TOR or a VPN can 1465 improve metadata protection. 1467 More generally, using anonymous credentials in an MLS based 1468 architecture might not be enough to provide strong privacy or 1469 anonymity properties. 1471 7.4.2. Delivery Service Compromise 1473 MLS is intended to provide strong guarantees in the face of 1474 compromise of the DS. Even a totally compromised DS should not be 1475 able to read messages or inject messages that will be acceptable to 1476 legitimate clients. It should also not be able to undetectably 1477 remove, reorder or replay messages. 1479 However, a DS can mount a variety of DoS attacks on the system, 1480 including total DoS attacks (where it simply refuses to forward any 1481 messages) and partial DoS attacks (where it refuses to forward 1482 messages to and from specific clients). As noted in Section 4.3, 1483 these attacks are only partially detectable by clients without an 1484 out-of-band channel. Ultimately, failure of the DS to provide 1485 reasonable service must be dealt with as a customer service matter, 1486 not via technology. 1488 Because the DS is responsible for providing the initial keying 1489 material to clients, it can provide stale keys. This does not 1490 inherently lead to compromise of the message stream, but does allow 1491 it to attack forward security to a limited extent. This threat can 1492 be mitigated by having initial keys expire. 1494 7.4.2.1. Privacy of delivery and push notifications 1496 An important mechanism that is often ignored from the privacy 1497 considerations are the push-tokens. In many modern messaging 1498 architectures, applications are using push notification mechanisms 1499 typically provided by OS vendors. This is to make sure that when 1500 messages are available at the Delivery Service (or by other 1501 mechanisms if the DS is not a central server), the recipient 1502 application on a device knows about it. Sometimes the push 1503 notification can contain the application message itself which saves a 1504 round trip with the DS. 1506 To "push" this information to the device, the service provider and 1507 the OS infrastructures use unique per-device, per-application 1508 identifiers called push-tokens. This means that the push 1509 notification provider and the service provider have information on 1510 which devices receive information and at which point in time. 1512 Even though they can't necessarily access the content, which is 1513 typically encrypted MLS messages, the service provider and the push 1514 notification provider have to be trusted to avoid making correlation 1515 on which devices are recipients of the same message. 1517 For secure messaging systems, push notification are often sent real- 1518 time as it is not acceptable to create artificial delays for message 1519 retrieval. 1521 *RECOMMENDATION:* If real time notifications are not necessary and 1522 that specific steps must be taken to improve privacy, one can 1523 delay notifications randomly across recipient devices using a 1524 mixnet or other techniques. 1526 Note that it is quite easy for legal requests to ask the service 1527 provider for the push-token associated to an identifier and perform a 1528 second request to the company operating the push-notification system 1529 to get information about the device, which is often linked with a 1530 real identity via a cloud account, a credit card or other 1531 information. 1533 *RECOMMENDATION:* If stronger privacy guarantees are needed vis- 1534 a-vis the push notification provider, the client can choose to 1535 periodically connect to the Delivery Service without the need of a 1536 dedicated push notification infrastructure. 1538 7.4.3. Authentication Service Compromise 1540 The Authentication Service design is left to the infrastructure 1541 designers. In most designs, a compromised AS is a serious matter, as 1542 the AS can serve incorrect or attacker-provided identities to 1543 clients. 1545 * The attacker can link an identity to a credential 1547 * The attacker can generate new credentials 1549 * The attacker can sign new credentials 1551 * The attacker can publish or distribute credentials 1553 Infrastructures that provide cryptographic material or credentials in 1554 place of the MLS client (which is under the control of the user) have 1555 often the ability to use the associated secrets to perform operations 1556 on behalf of the user, which is unacceptable in many situations. 1557 Other mechanisms can be used to prevent this issue, such as the 1558 service blessing cryptographic material used by an MLS client. 1560 *RECOMMENDATION:* Make clients submit signature public keys to the 1561 AS, this is usually better than the AS generating public key pairs 1562 because the AS cannot sign on behalf of the client. This is a 1563 benefit of a Public Key Infrastructure in the style of the 1564 Internet PKI. 1566 An attacker that can generate or sign new credentials may or may not 1567 have access to the underlying cryptographic material necessary to 1568 perform such operations. In that last case, it results in windows of 1569 time for which all emitted credentials might be compromised. 1571 *RECOMMENDATION:* Using HSMs to store the root signature keys to 1572 limit the ability of an adversary with no physical access to 1573 extract the top-level signature key. 1575 7.4.3.1. Authentication compromise: Ghost users and impersonations 1577 One thing for which the MLS Protocol is designed for is to make sure 1578 that all clients know who is in the group at all times. This means 1579 that - if all Members of the group and the Authentication Service are 1580 honest - no other parties than the members of the current group can 1581 read and write messages protected by the protocol for that Group. 1583 Beware though, the link between the cryptographic identity of the 1584 Client and the real identity of the User is important. With some 1585 Authentication Service designs, a private or centralized authority 1586 can be trusted to generate or validate signature keypairs used in the 1587 MLS protocol. This is typically the case in some of the biggest 1588 messaging infrastructures. 1590 While this service is often very well protected from external 1591 attackers, it might be the case that this service is compromised. In 1592 such infrastructure, the AS could generate or validate a signature 1593 keypair for an identity which is not the expected one. Because a 1594 user can have many MLS clients running the MLS protocol, it possibly 1595 has many signature keypairs for multiple devices. 1597 In the case where an adversarial keypair is generated for a specific 1598 identity, an infrastructure without any transparency mechanism or 1599 out-of-band authentication mechanism could inject a malicious client 1600 into a group by impersonating a user. This is especially the case in 1601 large groups where the UI might not reflect all the changes back to 1602 the users. 1604 *RECOMMENDATION:* Make sure that MLS clients reflect all the 1605 membership changes to the users as they happen. If a choice has 1606 to be made because the number of notifications is too high, a 1607 public log should be maintained in the state of the device so that 1608 the user can examine it. 1610 While the ways to handle MLS credentials are not defined by the 1611 protocol or the architecture documents, the MLS protocol has been 1612 designed with a mechanism that can be used to provide out-of-band 1613 authentication to users. The "authentication_secret" generated for 1614 each user at each epoch of the group is a one-time, per client, 1615 authentication secret which can be exchanged between users to prove 1616 their identity to each other. This can be done for instance using a 1617 QR code that can be scanned by the other parties. 1619 Another way to improve the security for the users is to provide a 1620 transparency mechanism which allows each user to check if credentials 1621 used in groups have been published in the transparency log. Another 1622 benefit of this mechanism is for revocation. The users of a group 1623 could check for revoked keys (in case of compromise detection) using 1624 a mechanism such as CRLite or some more advanced privacy preserving 1625 technology. 1627 *RECOMMENDATION:* Provide a Key Transparency and Out-of-Band 1628 authentication mechanisms to limit the impact of an Authentication 1629 Service compromise. 1631 We note, again, that as described prior to that section, the 1632 Authentication Service is facultative to design a working 1633 infrastructure and can be replaced by many mechanisms such as 1634 establishing prior one-to-one deniable channels, gossiping, or using 1635 TOFU for credentials used by the MLS Protocol. 1637 Another important consideration is the ease of redistributing new 1638 keys on client compromise, which helps recovering security faster in 1639 various cases. 1641 7.4.3.2. Privacy of the Group Membership 1643 Often, expectation from users is that the infrastructure will not 1644 retain the ability to constantly map the user identity to signature 1645 public keys of the MLS protocol. Some infrastructures will keep a 1646 mapping between signature public keys of clients and user identities. 1647 This can benefit an adversary that has compromised the AS (or 1648 required access according to regulation) the ability of monitoring 1649 unencrypted traffic and correlating the messages exchanged within the 1650 same group. 1652 *RECOMMENDATION:* Always use encrypted group operation messages to 1653 reduce issues related to privacy. 1655 In certain cases, the adversary can access specific bindings between 1656 public keys and identities. If the signature keys are reused across 1657 groups, the adversary can get more information about the targeted 1658 user. 1660 *RECOMMENDATION:* Do not use the same signature keypair across 1661 groups. 1663 *RECOMMENDATION:* Separate the service binding the identities and 1664 the public keys from the service which generates or validates the 1665 credentials or cryptographic material of the Clients. 1667 7.5. Considerations for attacks outside of the threat model 1669 Physical attacks on devices storing and executing MLS principals are 1670 not considered in depth in the threat model of the MLS protocol. 1671 While non-permanent, non-invasive attacks can sometimes be equivalent 1672 to software attacks, physical attacks are considered outside of the 1673 MLS threat model. 1675 Compromise scenarios typically consist in a software adversary, which 1676 can maintain active adaptive compromise and arbitrarily change the 1677 behavior of the client or service. 1679 On the other hand, security goals consider that honest clients will 1680 always run the protocol according to its specification. This relies 1681 on implementations of the protocol to securely implement the 1682 specification, which remains non-trivial. 1684 *RECOMMENDATION:* Additional steps should be taken to protect the 1685 device and the MLS clients from physical compromise. In such 1686 settings, HSMs and secure enclaves can be used to protect 1687 signature keys. 1689 7.6. Cryptographic Analysis of the MLS Protocol 1691 Various academic works have analyzed MLS and the different security 1692 guarantees it aims to provide. The security of large parts of the 1693 protocol has been analyzed by [BBN19] (draft 7), [ACDT21] (draft 11) 1694 and [AJM20] (draft 12). 1696 Individual components of various drafts of the MLS protocol have been 1697 analyzed in isolation and with differing adversarial models, for 1698 example, [BBR18], [ACDT19], [ACCKKMPPWY19], [AJM20] and [ACJM20] 1699 analyze the ratcheting tree as the sub-protocol of MLS that 1700 facilitates key agreement, while [BCK21] analyzes the key derivation 1701 paths in the ratchet tree and key schedule. Finally, [CHK19] 1702 analyzes the authentication and cross-group healing guarantees 1703 provided by MLS. 1705 8. Informative References 1707 * ACDT19: https://eprint.iacr.org/2019/1189 1709 * ACCKKMPPWY19: https://eprint.iacr.org/2019/1489 1711 * ACJM20: https://eprint.iacr.org/2020/752 1713 * AJM20: https://eprint.iacr.org/2020/1327 1715 * ACDT21: https://eprint.iacr.org/2021/1083 1717 * AHKM21: https://eprint.iacr.org/2021/1456 1719 * CHK19: https://eprint.iacr.org/2021/137 1721 * BCK21: https://eprint.iacr.org/2021/137 1723 * BBR18: https://hal.inria.fr/hal-02425247 1725 * BBN19: https://hal.laas.fr/INRIA/hal-02425229 1727 9. IANA Considerations 1729 This document makes no requests of IANA. 1731 10. References 1733 10.1. Normative References 1735 [I-D.ietf-mls-protocol] 1736 Barnes, R., Beurdouche, B., Robert, R., Millican, J., 1737 Omara, E., and K. Cohn-Gordon, "The Messaging Layer 1738 Security (MLS) Protocol", Work in Progress, Internet- 1739 Draft, draft-ietf-mls-protocol-14, 3 May 2022, 1740 . 1743 10.2. Informative References 1745 [I-D.mahy-mls-content-neg] 1746 Mahy, R., "Content Negotiation for Message Layer Security 1747 (MLS)", Work in Progress, Internet-Draft, draft-mahy-mls- 1748 content-neg-00, 31 March 2022, 1749 . 1752 [KeyTransparency] 1753 Google, "Key Transparency", 2017, 1754 . 1756 [Loopix] Piotrowska, A. M., Hayes, J., Elahi, T., Meiser, S., and 1757 G. Danezis, "The Loopix Anonymity System", 2017. 1759 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1760 Text on Security Considerations", BCP 72, RFC 3552, 1761 DOI 10.17487/RFC3552, July 2003, 1762 . 1764 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1765 Housley, R., and W. Polk, "Internet X.509 Public Key 1766 Infrastructure Certificate and Certificate Revocation List 1767 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1768 . 1770 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 1771 Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, 1772 March 2011, . 1774 Contributors 1776 Richard Barnes 1777 Cisco 1778 Email: rlb@ipv.sx 1780 Katriel Cohn-Gordon 1781 Meta Platforms 1782 Email: me@katriel.co.uk 1784 Cas Cremers 1785 CISPA Helmholtz Center for Information Security 1786 Email: cremers@cispa.de 1788 Britta Hale 1789 Naval Postgraduate School 1790 Email: britta.hale@nps.edu 1792 Konrad Kohbrok 1793 Email: konrad.kohbrok@datashrine.de 1795 Brendan McMillion 1796 Email: brendanmcmillion@gmail.com 1798 Thyla van der Merwe 1799 Email: tjvdmerwe@gmail.com 1801 Jon Millican 1802 Meta Platforms 1803 Email: jmillican@fb.com 1805 Raphael Robert 1806 Email: ietf@raphaelrobert.com 1808 Authors' Addresses 1810 Benjamin Beurdouche 1811 Inria & Mozilla 1812 Email: ietf@beurdouche.com 1813 Eric Rescorla 1814 Mozilla 1815 Email: ekr@rtfm.com 1817 Emad Omara 1818 Google 1819 Email: emadomara@google.com 1821 Srinivas Inguva 1822 Twitter 1823 Email: singuva@twitter.com 1825 Albert Kwon 1826 MIT 1827 Email: kwonal@mit.edu 1829 Alan Duric 1830 Wire 1831 Email: alan@wire.com