idnits 2.17.1 draft-ietf-mls-architecture-06.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 ([MLSPROTO]), 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 466: '... means that the DS MUST enforce global...' RFC 2119 keyword, line 512: '...sisted for functionality, it SHOULD be...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (8 March 2021) is 1117 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 7049 (Obsoleted by RFC 8949) -- Obsolete informational reference (is this intentional?): RFC 7159 (Obsoleted by RFC 8259) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Omara 3 Internet-Draft Google 4 Intended status: Informational B. Beurdouche 5 Expires: 9 September 2021 Inria & Mozilla 6 E. Rescorla 7 Mozilla 8 S. Inguva 9 Twitter 10 A. Kwon 11 MIT 12 A. Duric 13 Wire 14 8 March 2021 16 The Messaging Layer Security (MLS) Architecture 17 draft-ietf-mls-architecture-06 19 Abstract 21 The Messaging Layer Security (MLS) protocol [MLSPROTO] document has 22 the role of defining a Group Key Agreement, all the necessary 23 cryptographic operations, and serialization/deserialization functions 24 necessary to create a scalable and secure group messaging protocol. 25 The MLS protocol is meant to protect against eavesdropping, 26 tampering, message forgery, and provide good properties such as 27 forward-secrecy (FS) and post-compromise security (PCS) in the case 28 of past or future device compromises. 30 This document, on the other hand is intended to describe a general 31 secure group messaging infrastructure and its security goals. It 32 provides guidance on building a group messaging system and discusses 33 security and privacy tradeoffs offered by multiple security mechanism 34 that are part of the MLS protocol (ie. frequency of public encryption 35 key rotation). 37 The document also extends the guidance to parts of the infrastructure 38 that are not standardized by the MLS Protocol document and left to 39 the application or the infrastructure architects to design. 41 While the recommendations of this document are not mandatory to 42 follow in order to interoperate at the protocol level, most will 43 vastly influence the overall security guarantees that are achieved by 44 the overall messaging system. This is especially true in case of 45 active adversaries that are able to compromise clients, the delivery 46 service or the authentication service. 48 Discussion Venues 49 This note is to be removed before publishing as an RFC. 51 Discussion of this document takes place on the MLS Working Group 52 mailing list (mls@ietf.org), which is archived at 53 https://mailarchive.ietf.org/arch/browse/mls/. 55 Source for this draft and an issue tracker can be found at 56 https://github.com/mlswg/mls-architecture. 58 Status of This Memo 60 This Internet-Draft is submitted in full conformance with the 61 provisions of BCP 78 and BCP 79. 63 Internet-Drafts are working documents of the Internet Engineering 64 Task Force (IETF). Note that other groups may also distribute 65 working documents as Internet-Drafts. The list of current Internet- 66 Drafts is at https://datatracker.ietf.org/drafts/current/. 68 Internet-Drafts are draft documents valid for a maximum of six months 69 and may be updated, replaced, or obsoleted by other documents at any 70 time. It is inappropriate to use Internet-Drafts as reference 71 material or to cite them other than as "work in progress." 73 This Internet-Draft will expire on 9 September 2021. 75 Copyright Notice 77 Copyright (c) 2021 IETF Trust and the persons identified as the 78 document authors. All rights reserved. 80 This document is subject to BCP 78 and the IETF Trust's Legal 81 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 82 license-info) in effect on the date of publication of this document. 83 Please review these documents carefully, as they describe your rights 84 and restrictions with respect to this document. Code Components 85 extracted from this document must include Simplified BSD License text 86 as described in Section 4.e of the Trust Legal Provisions and are 87 provided without warranty as described in the Simplified BSD License. 89 Table of Contents 91 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 92 2. General Setting . . . . . . . . . . . . . . . . . . . . . . . 4 93 2.1. Group, Members and Clients . . . . . . . . . . . . . . . 7 94 2.2. Authentication Service . . . . . . . . . . . . . . . . . 8 95 2.3. Delivery Service . . . . . . . . . . . . . . . . . . . . 9 96 2.3.1. Key Storage . . . . . . . . . . . . . . . . . . . . . 10 97 2.3.2. Key Retrieval . . . . . . . . . . . . . . . . . . . . 10 98 2.3.3. Delivery of messages and attachments . . . . . . . . 10 99 2.3.4. Membership knowledge . . . . . . . . . . . . . . . . 11 100 2.3.5. Membership and offline members . . . . . . . . . . . 12 101 2.4. Functional Requirements . . . . . . . . . . . . . . . . . 12 102 2.4.1. Message Secrecy and Authentication . . . . . . . . . 12 103 2.4.2. Forward and Post-Compromise Security . . . . . . . . 13 104 2.4.3. Membership Changes . . . . . . . . . . . . . . . . . 13 105 2.4.4. Parallel Groups . . . . . . . . . . . . . . . . . . . 14 106 2.4.5. Security of Attachments . . . . . . . . . . . . . . . 14 107 2.4.6. Non-Repudiation vs Deniability . . . . . . . . . . . 14 108 2.4.7. Asynchronous Usage . . . . . . . . . . . . . . . . . 15 109 2.4.8. Access Control . . . . . . . . . . . . . . . . . . . 15 110 2.4.9. Recovery After State Loss . . . . . . . . . . . . . . 16 111 2.4.10. Support for Multiple Devices . . . . . . . . . . . . 16 112 2.4.11. Extensibility / Pluggability . . . . . . . . . . . . 16 113 2.4.12. Federation . . . . . . . . . . . . . . . . . . . . . 16 114 2.4.13. Compatibility with future versions of MLS . . . . . . 17 115 3. Security and Privacy Considerations . . . . . . . . . . . . . 17 116 3.1. Considerations for attacks outside of the threat model . 18 117 3.2. Transport Security Links . . . . . . . . . . . . . . . . 18 118 3.2.1. Metadata protection for unencrypted group 119 operations . . . . . . . . . . . . . . . . . . . . . 18 120 3.2.2. DoS protection . . . . . . . . . . . . . . . . . . . 19 121 3.2.3. Message suppression and error correction . . . . . . 20 122 3.3. Delivery Service Compromise . . . . . . . . . . . . . . . 20 123 3.3.1. Privacy of delivery and push notifications . . . . . 21 124 3.4. Authentication Service Compromise . . . . . . . . . . . . 22 125 3.4.1. Authentication compromise: Ghost users and 126 impersonations . . . . . . . . . . . . . . . . . . . 23 127 3.4.2. Privacy of the Group Membership . . . . . . . . . . . 24 128 3.5. Shared considerations regarding adversarial AS or DS 129 services . . . . . . . . . . . . . . . . . . . . . . . . 24 130 3.5.1. Privacy of the network connections . . . . . . . . . 25 131 3.6. Client Compromise . . . . . . . . . . . . . . . . . . . . 25 132 3.6.1. Compromise of AEAD key material . . . . . . . . . . . 26 133 3.6.2. Compromise of the Group Secrets of a single group for 134 one or more group epochs . . . . . . . . . . . . . . 27 135 3.6.3. Compromise by an active adversary with the ability to 136 sign messages . . . . . . . . . . . . . . . . . . . . 28 137 3.6.4. Compromise of the authentication with access to a 138 signature key . . . . . . . . . . . . . . . . . . . . 28 139 3.6.5. Security consideration in the context of a full state 140 compromise . . . . . . . . . . . . . . . . . . . . . 29 141 3.6.6. More attack scenarios . . . . . . . . . . . . . . . . 31 142 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 143 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31 144 6. Informative References . . . . . . . . . . . . . . . . . . . 31 145 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 147 1. Introduction 149 RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH 151 The source for this draft is maintained in GitHub. Suggested changes 152 should be submitted as pull requests at https://github.com/mlswg/mls- 153 architecture. Instructions are on that page as well. Editorial 154 changes can be managed in GitHub, but any substantive change should 155 be discussed on the MLS mailing list. 157 DISCLAIMER: A lot of work is still ongoing on the current version of 158 this draft. Especially, this preliminary writing of the security 159 considerations has not been reviewed by the working group yet and 160 might contain errors. Please file an issue on the document's GitHub 161 if you find errors. 163 [[TODO: Remove disclaimer.]] 165 End-to-end security is a requirement for instant messaging systems 166 and is commonly deployed in many such systems. In this context, 167 "end-to-end" captures the notion that users of the system enjoy some 168 level of security -- with the precise level depending on the system 169 design -- even when the service provider they are using performs 170 unsatisfactorily. 172 Messaging Layer Security (MLS) specifies an architecture (this 173 document) and an abstract protocol [MLSPROTO] for providing end-to- 174 end security in this setting. MLS is not intended as a full instant 175 messaging protocol but rather is intended to be embedded in concrete 176 protocols, such as XMPP [RFC6120]. In addition, it does not specify 177 a complete wire encoding, but rather a set of abstract data 178 structures which can then be mapped onto a variety of concrete 179 encodings, such as TLS [RFC8446], CBOR [RFC7049], and JSON [RFC7159]. 180 Implementations which adopt compatible encodings will have some 181 degree of interoperability at the message level, though they may have 182 incompatible identity/authentication infrastructures. The MLS 183 protocol has been designed to provide the same security guarantees to 184 all users, for all group sizes, even when it reduces to only two 185 users. 187 2. General Setting 189 Informally, a group is a set of users who possibly use multiple 190 endpoint devices to interact with the Service Provider (SP). A group 191 may be as small as two members (the simple case of person to person 192 messaging) or as large as thousands. 194 In order to communicate securely, users initially interact with 195 services at their disposal to establish the necessary values and 196 credentials required for encryption and authentication. 198 The Service Provider presents two abstract functionalities that allow 199 clients to prepare for sending and receiving messages securely: 201 * An Authentication Service (AS) functionality which is responsible 202 for maintaining a binding between a unique identifier (identity) 203 and the public key material (credential) used for authentication 204 in the MLS protocol. This functionality must also be able to 205 generate these credentials or validate them if they are provided 206 by MLS clients. 208 * A Delivery Service (DS) functionality which can receive and 209 redistributing messages between group members. In the case of 210 group messaging, the delivery service may also be responsible for 211 acting as a "broadcaster" where the sender sends a single message 212 which is then forwarded to each recipient in the group by the DS. 213 The DS is also responsible for storing and delivering initial 214 public key material required by MLS clients in order to proceed 215 with the group secret key establishment that is part of the MLS 216 protocol. 218 For convenience, this document adopts the representation of these 219 services being standalone servers, however the MLS protocol design is 220 made so that it is not necessarily the case. 222 It is important to note that the Authentication Service functionality 223 can be completely abstract in the case of a Service Provider which 224 allows MLS clients to generate, redistribute and validate their 225 credentials themselves. 227 Similarly to the AS, the Delivery Service can be completely abstract 228 if users are able to distribute credentials and messages without 229 relying on a central Delivery Service. Note, though, that the MLS 230 protocol requires group operation messages to be processed in-order 231 by all MLS clients. 233 In some sense, a set of MLS clients which can achieve the AS and DS 234 functionalities without relying on an external party do not need a 235 Service Provider. 237 ---------------- -------------- 238 | Authentication | | Delivery | 239 | Service (AS) | | Service (DS) | 240 ---------------- -------------- 241 / | \ Group 242 / ************************************ 243 / * | \ * 244 ---------- * ---------- ---------- * 245 | Client 0 | * | Member 1 | | Member N | * 246 ---------- * ---------- ---------- * 247 ............ * ............ ............ * 248 User 0 * User 0 User 1 * 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 2.4.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; 284 * 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 by 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 and its signature key pair uniquely defines its identity to 326 other clients or members in the Group. In some messaging systems, 327 clients belonging to the same user must all share the same identity 328 key pair, but MLS does not assume this. 330 Users will typically own multiple Clients, potentially one or more 331 per end-user devices (phones, web clients or other devices...) and 332 may choose to authenticate using the same signature key across 333 devices, using one signature key per device or even one signature key 334 per group. 336 The formal definition of a Group in MLS is the set of clients that 337 have knowledge of the shared group secret established in the group 338 key establishment phase of the protocol and have contributed to it. 339 Until a Member has contributed to the group secret, other members 340 cannot assume they are a member of the group. 342 2.2. Authentication Service 344 The basic function of the Authentication Service (AS) is to provide a 345 trusted mapping from user identities (usernames, phone numbers, 346 etc.), to long-term identity keys, which may either be one per Client 347 or may be shared amongst the clients attached to a user. 349 The Authentication Service (AS) is expected to play multiple roles in 350 the architecture: 352 * A certification authority or similar service which signs some sort 353 of portable credential binding an identity to a signature key. 355 * A directory server which provides the key for a given identity 356 (presumably this connection is secured via some form of transport 357 security such as TLS). 359 The MLS protocol assumes a signature keypair for authentication of 360 messages. It is important to note that this signature keypair might 361 be the identity keypair itself, or a different signature keypair for 362 which the public key has been, for example, signed by the identity 363 private key. This flexibility allows for multiple infrastructure 364 considerations and has the benefit of providing ways to use different 365 signature keys across different groups by using hierarchical 366 authentication keys. This flexibility also comes at the price of a 367 security tradeoff, described in the security considerations, between 368 potential unlinkability of the signature keys across groups and the 369 amount of time required to reinstate authentication and secrecy of 370 messages after the compromise of a device. 372 Ultimately, the only requirement is for the applications to be able 373 to check the credential containing the protocol signing key and the 374 identity against the Authentication Service at any time. 376 By definition, the Authentication Service is invested with a large 377 amount of trust. A malicious AS can impersonate -- or allow an 378 attacker to impersonate -- any user of the system. As a corollary, 379 by impersonating identities authorized to be members of a group, an 380 AS can break confidentiality. 382 This risk can be mitigated by publishing the binding between 383 identities and keys in a public log such as Key Transparency (KT) 384 [KeyTransparency]. It is possible to build a functional MLS system 385 without any kind of public key logging, but such a system will 386 necessarily be somewhat vulnerable to attack by a malicious or 387 untrusted AS. 389 2.3. Delivery Service 391 The Delivery Service (DS) is expected to play multiple roles in the 392 Service Provider architecture: 394 * To act as a directory service providing the initial keying 395 material for clients to use. This allows a client to establish a 396 shared key and send encrypted messages to other clients even if 397 the other client is offline. 399 * To route messages between clients and to act as a message 400 broadcaster, taking in one message and forwarding it to multiple 401 clients (also known as "server side fanout"). 403 Because the MLS protocol provides a way for Clients to send and 404 receive application messages asynchronously, it only provides causal 405 ordering of application messages from senders while it has to enforce 406 global ordering of group operations to provide Group Agreement. 408 Depending on the level of trust given by the group to the Delivery 409 Service, the functional and privacy guarantees provided by MLS may 410 differ but the Authentication and Confidentiality guarantees remain 411 the same. 413 Unlike the Authentication Service which is trusted for authentication 414 and secrecy, the Delivery Service is completely untrusted regarding 415 this property. While privacy of group membership might be a problem 416 in the case of a DS server fanout, the Delivery Service can be 417 considered as an active adaptative network attacker from the point of 418 view of the security analysis. 420 2.3.1. Key Storage 422 Upon joining the system, each client stores its initial cryptographic 423 key material with the Delivery Service. This key material, called 424 KeyPackage, advertises the functional abilities of the Client such as 425 supported protocol versions and extensions and the following 426 cryptographic information: 428 * A credential from the Authentication Service attesting to the 429 binding between the identity and the client's signature key. 431 * The client's asymmetric encryption public key material signed with 432 the signature public key associated with the credential. 434 As noted above, users may own multiple clients, each with their own 435 keying material, and thus there may be multiple entries stored by 436 each user. 438 The Delivery Service is also responsible for allowing users to add, 439 remove or update their initial keying material and to ensure that the 440 identifier for these keys are unique across all keys stored on the 441 DS. 443 2.3.2. Key Retrieval 445 When a client wishes to establish a group, it first contacts the DS 446 to request a KeyPackage for each other client, authenticate it using 447 the signature keys, and then can use those to form the group. 449 2.3.3. Delivery of messages and attachments 451 The main responsibility of the Delivery Service is to ensure delivery 452 of messages. Specifically, we assume that DSs provide: 454 * Reliable delivery: when a message is provided to the DS, it is 455 eventually delivered to all clients. 457 * In-order delivery: messages are delivered to the group in the 458 order they are received by the Delivery Service and in 459 approximately the order in which they are sent by clients. The 460 latter is an approximate guarantee because multiple clients may 461 send messages at the same time and so the DS needs some latitude 462 in enforcing ordering across clients. 464 * Consistent ordering: the DS must ensure that all clients have the 465 same view of message ordering for cryptographically relevant 466 operations. This means that the DS MUST enforce global 467 consistency of the ordering of group operation messages. 469 Note that the protocol provides three important information within an 470 MLSCiphertext message in order to provide ordering: 472 * The Group Identifier (GID) to allow to distinguish the group for 473 which the message has been sent; 475 * The Epoch number, which represent the number of changes (version) 476 of the group associated with a specific GID, and allows for 477 lexicographical ordering of two messages from the same group; 479 * The Content Type of the message, which allows the DS to determine 480 the ordering requirement on the message. 482 The MLS protocol itself can verify these properties. For instance, 483 if the DS reorders messages from a Client or provides different 484 Clients with inconsistent orderings, then Clients can detect this 485 misconduct. However, the protocol relies on the ordering, and on the 486 fact that only one honest group operation message is fanned-out to 487 clients per Epoch, to provide Clients with a consistent view of the 488 evolving Group State. 490 Note that some forms of DS misbehavior are still possible and 491 difficult to detect. For instance, a DS can simply refuse to relay 492 messages to and from a given client. Without some sort of side 493 information, other clients cannot generally distinguish this form of 494 Denial of Service (DoS) attack. 496 2.3.4. Membership knowledge 498 Group membership is itself sensitive information and MLS is designed 499 to drastically limit the amount of persisted metadata. However, 500 large groups often require an infrastructure which provides server 501 fanout. In the case of client fanout, the destinations of a message 502 is known by all clients, hence the server usually does not need this 503 information. However, they may learn this information through 504 traffic analysis. Unfortunately, in a server side fanout model, the 505 DS can learn that a given client is sending the same message to a set 506 of other clients. In addition, there may be applications of MLS in 507 which the group membership list is stored on some server associated 508 with the DS. 510 While this knowledge is not a break of authentication or 511 confidentiality, it is a serious issue for privacy. In the case 512 where metadata has to be persisted for functionality, it SHOULD be 513 stored encrypted at rest. 515 2.3.5. Membership and offline members 517 Because Forward Secrecy (FS) and Post-Compromise Security (PCS) rely 518 on the active deletion and replacement of keying material, any client 519 which is persistently offline may still be holding old keying 520 material and thus be a threat to both FS and PCS if it is later 521 compromised. 523 MLS cannot inherently defend against this problem, especially in the 524 case where the Client hasn't processed messages but MLS-using systems 525 can enforce some mechanism to try retaining these properties. 526 Typically this will consist of evicting clients which are idle for 527 too long, thus containing the threat of compromise. The precise 528 details of such mechanisms are a matter of local policy and beyond 529 the scope of this document. 531 2.4. Functional Requirements 533 MLS is designed as a large scale group messaging protocol and hence 534 aims to provide performance and safety to its users. Messaging 535 systems that implement MLS provide support for conversations 536 involving two or more members, and aim to scale to groups as large as 537 50,000 members, typically including many users using multiple 538 devices. 540 2.4.1. Message Secrecy and Authentication 542 The trust establishment step of the MLS protocol is followed by a 543 conversation protection step where encryption is used by clients to 544 transmit authenticated messages to other clients through the DS. 545 This ensures that the DS does not have access to the group's private 546 content. 548 MLS aims to provide secrecy, integrity and authentication for all 549 messages. 551 Message Secrecy in the context of MLS means that only intended 552 recipients (current group members), can read any message sent to the 553 group, even in the context of an active attacker as described in the 554 threat model. 556 Message Integrity and Authentication mean that an honest Client can 557 only accept a message if it was sent by a group member and that no 558 Client can send a message which other Clients accept as being from 559 another Client. 561 A corollary to this statement is that the AS and the DS cannot read 562 the content of messages sent between Members as they are not Members 563 of the Group. MLS optionally provides additional protections 564 regarding traffic analysis so as to reduce the ability of attackers, 565 or a compromised member of the messaging system, to deduce the 566 content of the messages depending on (for example) their size. One 567 of these protections includes padding messages in order to produce 568 ciphertexts of standard length. While this protection is highly 569 recommended it is not mandatory as it can be costly in terms of 570 performance for clients and the SP. 572 Message content can be deniable if the signature keys are exchanged 573 over a deniable channel prior to signing messages. 575 2.4.2. Forward and Post-Compromise Security 577 MLS provides additional protection regarding secrecy of past messages 578 and future messages. These cryptographic security properties are 579 Forward Secrecy (FS) and Post-Compromise Security (PCS). 581 FS means that access to all encrypted traffic history combined with 582 an access to all current keying material on clients will not defeat 583 the secrecy properties of messages older than the oldest key of the 584 compromised client. Note that this means that clients have the 585 extremely important role of deleting appropriate keys as soon as they 586 have been used with the expected message, otherwise the secrecy of 587 the messages and the security for MLS is considerably weakened. 589 PCS means that if a group member's state is compromised at some time 590 t but the group member subsequently performs an update at some time 591 t', then all MLS guarantees apply to messages sent by the member 592 after time t', and by other members after they have processed the 593 update. For example, if an attacker learns all secrets known to 594 Alice at time t, including both Alice's long-term secret keys and all 595 shared group keys, but Alice performs a key update at time t', then 596 the attacker is unable to violate any of the MLS security properties 597 after the updates have been processed. 599 Both of these properties are satisfied even against compromised DSs 600 and ASs. 602 2.4.3. Membership Changes 604 MLS aims to provide agreement on group membership, meaning that all 605 group members have agreed on the list of current group members. 607 Some applications may wish to enforce ACLs to limit addition or 608 removal of group members, to privileged clients or users. Others may 609 wish to require authorization from the current group members or a 610 subset thereof. Regardless, MLS does not allow addition or removal 611 of group members without informing all other members. 613 Once a client is part of a group, the set of devices controlled by 614 the user can only be altered by an authorized member of the group. 615 This authorization could depend on the application: some applications 616 might want to allow certain other members of the group to add or 617 remove devices on behalf of another member, while other applications 618 might want a more strict policy and allow only the owner of the 619 devices to add or remove them at the potential cost of weaker PCS 620 guarantees. 622 Members who are removed from a group do not enjoy special privileges: 623 compromise of a removed group member does not affect the security of 624 messages sent after their removal but might affect previous messages 625 if the group secrets have not been deleted properly. 627 2.4.4. Parallel Groups 629 Any user may have membership in several Groups simultaneously. The 630 set of members of any group may or may not form a subset of the 631 members of another group. MLS guarantees that the FS and PCS goals 632 are maintained and not weakened by user membership in multiple 633 groups. 635 2.4.5. Security of Attachments 637 The security properties expected for attachments in the MLS protocol 638 are very similar to the ones expected from messages. The distinction 639 between messages and attachments stems from the fact that the typical 640 average time between the download of a message and the one from the 641 attachments may be different. For many reasons (a typical reason 642 being the lack of high bandwidth network connectivity), the lifetime 643 of the cryptographic keys for attachments is usually higher than for 644 messages, hence slightly weakening the PCS guarantees for 645 attachments. 647 2.4.6. Non-Repudiation vs Deniability 649 As described in Section 3.6, MLS provides strong authentication 650 within a group, such that a group member cannot send a message that 651 appears to be from another group member. Additionally, some services 652 require that a recipient be able to prove to the service provider 653 that a message was sent by a given client, in order to report abuse. 654 MLS supports both of these use cases. In some deployments, these 655 services are provided by mechanisms which allow the receiver to prove 656 a message's origin to a third party (this if often called "non- 657 repudiation"), but it should also be possible to operate MLS in a 658 "deniable" mode where such proof is not possible. 660 2.4.7. Asynchronous Usage 662 No operation in MLS requires two distinct clients or members to be 663 online simultaneously. In particular, members participating in 664 conversations protected using MLS can update shared keys, add or 665 remove new members, and send messages and attachments without waiting 666 for another user's reply. 668 Messaging systems that implement MLS have to provide a transport 669 layer for delivering messages asynchronously and reliably. 671 2.4.8. Access Control 673 The MLS protocol allows each member of the messaging group to perform 674 operations equally. This is because all clients within a group 675 (members) have access to the shared cryptographic material. However 676 every service/infrastructure have control over policies applied to 677 their own clients. Applications managing MLS clients can be 678 configured to allow for specific Group operations. An application 679 can, for example, decide to provide specific permissions to a group 680 administrator that will be the one to perform add and remove 681 operations, but the flexibility is immense here. On the other hand, 682 in many settings such as open discussion forums, joining can be 683 allowed for anyone. 685 The MLS protocol can in certain modes can exchange unencrypted group 686 operation messages. This flexibility is to allow services to perform 687 access control tasks on behalf of the group. 689 While the Application messages will always be encrypted, having the 690 handshake messages in plaintext has inconveniences in terms of 691 privacy as someone could collect the signatures on the handshake 692 messages and use it for tracking. 694 *RECOMMENDATION:* Prefer using encrypted group operation messages 695 to avoid privacy issues related to non-encrypted signatures. 697 Note that in the default case of encrypted handshake messages, the 698 application level must make sure that the access control policies are 699 consistent across all clients to make sure that they remain in sync. 700 If two different policies were applied, the clients might not accept 701 or reject a group operation and end-up in different cryptographic 702 states, breaking their ability to communicate. 704 *RECOMMENDATION:* Avoid using inconsistent access control policies 705 in the case of encrypted group operations. 707 2.4.9. Recovery After State Loss 709 Conversation participants whose local MLS state is lost or corrupted 710 can reinitialize their state and continue participating in the 711 conversation. 713 [[OPEN ISSUE: The previous statement seems too strong, establish what 714 exact functional requirement we have regarding state recovery. 715 Previously: "This may entail some level of message loss, but does not 716 result in permanent exclusion from the group."]] 718 2.4.10. Support for Multiple Devices 720 It is typically expected for users within a Group to own different 721 devices. 723 A new device can be added to a group and be considered as a new 724 client by the protocol. This client will not gain access to the 725 history even if it is owned by someone who owns another member of the 726 Group. Restoring history is typically not allowed at the protocol 727 level but applications can elect to provide such a mechanism outside 728 of MLS. Such mechanisms, if used, may undermine the FS and PCS 729 guarantees provided by MLS. 731 2.4.11. Extensibility / Pluggability 733 Messages that do not affect the group state can carry an arbitrary 734 payload with the purpose of sharing that payload between group 735 members. No assumptions are made about the format of the payload. 737 2.4.12. Federation 739 The protocol aims to be compatible with federated environments. 740 While this document does not specify all necessary mechanisms 741 required for federation, multiple MLS implementations can 742 interoperate to form federated systems if they use compatible 743 authentication mechanisms and infrastructure functionalities. 745 2.4.13. Compatibility with future versions of MLS 747 It is important that multiple versions of MLS be able to coexist in 748 the future. Thus, MLS offers a version negotiation mechanism; this 749 mechanism prevents version downgrade attacks where an attacker would 750 actively rewrite messages with a lower protocol version than the ones 751 originally offered by the endpoints. When multiple versions of MLS 752 are available, the negotiation protocol guarantees that the version 753 agreed upon will be the highest version supported in common by the 754 group. 756 In MLS 1.0, the creator of the group is responsible for selecting the 757 best ciphersuite proposed across clients. Each client is able to 758 verify availability of protocol version, ciphersuites and extensions 759 at all times once he has at least received the first group operation 760 message. 762 3. Security and Privacy Considerations 764 MLS adopts the Internet threat model [RFC3552] and therefore assumes 765 that the attacker has complete control of the network. It is 766 intended to provide the security services described in the face of 767 such attackers. 769 -- The attacker can monitor the entire network 771 -- The attacker can read unprotected messages 773 -- The attacker can generate and inject any message in the 774 unprotected transport layer. 776 In addition, these guarantees are intended to degrade gracefully in 777 the presence of compromise of the transport security links as well as 778 of both Clients and elements of the messaging system, as described in 779 the remainder of this section. 781 Generally, MLS is designed under the assumption that the transport 782 layer is present to protect metadata and privacy in general, while 783 the MLS protocol is providing stronger guarantees such as 784 confidentiality, integrity and authentication guarantees. Stronger 785 properties such as deniability can also be achieved in specific 786 architecture designs. 788 3.1. Considerations for attacks outside of the threat model 790 Physical attacks on devices storing and executing MLS principals are 791 not considered in depth in the threat model of the MLS protocol. 792 While non-permanent, non-invasive attacks can sometime be equivalent 793 to software attacks, physical attacks are considered outside of the 794 MLS threat model. 796 Compromise scenarios, typically consist in a software adversary, 797 which can maintain active adaptative compromise and arbitrarily 798 change the behavior of the client or service. 800 On the other hand, security goals consider that honest clients will 801 always run the protocol according to its specification. This relies 802 on implementations of the protocol to securely implement the 803 specification, which remains non-trivial. 805 *RECOMMENDATION:* Additional steps should be taken to protect the 806 device and the MLS clients from physical compromise. In such 807 setting, HSMs and secure enclaves can be used to protect signature 808 keys. 810 More information will be available in the Server-Assist draft. 812 [[TODO: Reference to server assist when the draft is available.]] 814 3.2. Transport Security Links 816 Any secure channel can be used as a transport layer to protect MLS 817 messages such as QUIC, TLS, WireGuard or TOR. Though the MLS 818 protocol is designed to consider the following threat-model: 820 -- The attacker can read and write arbitrary messages inside the 821 secure transport channel. 823 This departs from most threat models where we consider that the 824 secure channel used for transport always provides secrecy. The 825 reason for this consideration is that in the group setting active 826 malicious insiders or adversarial services are be considered. 828 3.2.1. Metadata protection for unencrypted group operations 830 The main use of the secure transport layer for MLS is to protect the 831 already limited amount of metadata. Very little information is 832 contained in the unencrypted header of the MLS Protocol message 833 format for group operation messages, and application messages are 834 always encrypted in MLS. 836 Contrary to popular messaging services, the full list of recipients 837 cannot be sent to the server for dispatching messages because that 838 list is potentially extremely large in MLS. So, the metadata 839 typically consists of a pseudo-random Group Identifier (GID), an 840 numerical index referring to the key needed to decrypt the ciphertext 841 content and another numerical value to determine the epoch of the 842 group (the number of group operations that have been performed). 844 MLS protocol provides an authenticated "Authenticated Additional 845 Data" field for application to make data available outside the 846 MLSCiphertext. 848 *RECOMMENDATION:* Use the "Authenticated Additional Data" field of 849 the MLSCiphertext message instead of using other unauthenticated 850 means of sending metadata throughout the infrastructure. If the 851 data is private, the infrastructure should use encrypted 852 Application messages instead. 854 Even though, some of these metadata information are not secret 855 payloads, in correlation with other data, a network observer might be 856 able to reconstruct sensitive information. Using a secure channel to 857 transfer this information will prevent a network attacker to access 858 this MLS protocol metadata if it cannot compromise the secure 859 channel. 861 More importantly, there is one specific case where having no secure 862 channel to exchange the MLS messages can have a serious impact on 863 privacy. In the case of unencrypted group operation messages, 864 observing the signatures of the Group Operation messages may lead an 865 adversary to extract information about the group memberships. 867 *RECOMMENDATION:* Never use the unencrypted mode for group 868 operations without using a secure channel for the transport layer. 870 3.2.2. DoS protection 872 In general we do not consider Denial of Service (DoS) resistance to 873 be the responsibility of the protocol. However, it should not be 874 possible for anyone aside from the DS to perform a trivial DoS attack 875 from which it is hard to recover. This can be achieved through the 876 secure transport layer. 878 In the centralized setting DoS protection can typically be performed 879 by using tickets or cookies which identify users to a service for a 880 certain number of connections. Such a system helps preventing 881 anonymous clients to send arbitrary numbers of Group Operation 882 messages to the Delivery Service or the MLS clients. 884 *RECOMMENDATION:* Anonymous credentials can be used in order to 885 help DoS attacks prevention, in a privacy preserving manner. Note 886 that the privacy of these mechanisms has to be adjusted in 887 accordance with the privacy expected from the secure transport 888 links. (See more discussion further down.) 890 3.2.3. Message suppression and error correction 892 The MLS protocol is particularly sensitive about Group Operation 893 message loss and reordering. This is because in the default setting, 894 MLS clients have to process those specific messages in order to have 895 a synchronized group state, after what the MLS protocol efficiently 896 generates keys for application messages. 898 The Delivery Service can have the role of helping with reliability, 899 but is mainly useful for reliability in the asynchronous aspect of 900 the communication between MLS clients. 902 While it is difficult or impossible to prevent a network adversary to 903 suppress payloads in transit, in certain infrastructures such as 904 banks or governments settings, unidirectional transports can be used 905 and be enforced via electronic or physical devices such as diodes. 906 This can lead to payload corruption which does not affect the 907 security or privacy properties of the MLS Protocol but does affect 908 the reliability of the service. In that case specific measures can 909 be taken to ensure the appropriate level of redundancy and quality of 910 service for MLS. 912 *RECOMMENDATION:* If unidirectional transport is used for the 913 secure transport channel, prefer using a protocol which provides 914 Forward Error Correction. 916 3.3. Delivery Service Compromise 918 MLS is intended to provide strong guarantees in the face of 919 compromise of the DS. Even a totally compromised DS should not be 920 able to read messages or inject messages that will be acceptable to 921 legitimate clients. It should also not be able to undetectably 922 remove, reorder or replay messages. 924 However, a DS can mount a variety of DoS attacks on the system, 925 including total DoS attacks (where it simply refuses to forward any 926 messages) and partial DoS attacks (where it refuses to forward 927 messages to and from specific clients). As noted in Section 2.3.3, 928 these attacks are only partially detectable by clients without an 929 out-of-band channel. Ultimately, failure of the DS to provide 930 reasonable service must be dealt with as a customer service matter, 931 not via technology. 933 Because the DS is responsible for providing the initial keying 934 material to clients, it can provide stale keys. This does not 935 inherently lead to compromise of the message stream, but does allow 936 it to attack forward security to a limited extent. This threat can 937 be mitigated by having initial keys expire. 939 3.3.1. Privacy of delivery and push notifications 941 An important mechanism that is often ignored from the privacy 942 considerations are the push-tokens. In many modern messaging 943 architectures, applications are using push notification mechanisms 944 typically provided by OS vendors. This is to make sure that when 945 messages are available at the Delivery Service (or by other 946 mechanisms if the DS is not a central server), the recipient 947 application on a device knows about it. Sometimes the push 948 notification can contain the application message itself which saves a 949 round trip with the DS. 951 To "push" this information to the device, the service provider and 952 the OS infrastructures use unique per-device, per-application 953 identifiers called push-tokens. This means that the push 954 notification provider and the service provider have information on 955 which devices receive information and at which point in time. 957 Even though they can't necessarily access the content, which is 958 typically encrypted MLS messages, the service provider and the push 959 notification provider have to be trusted to avoid making correlation 960 on which devices are recipients of the same message. 962 For secure messaging systems, push notification are often sent real- 963 time as it is not acceptable to create artificial delays for message 964 retrieval. 966 *RECOMMENDATION:* If real time notification are not necessary and 967 that specific steps must be taken to improve privacy, one can 968 delay notifications randomly across recipient devices using a 969 mixnet or other techniques. 971 Note that it is quite easy for legal requests to ask the service 972 provider for the push-token associated to an identifier and perform a 973 second request to the company operating the push-notification system 974 to get information about the device, which is often linked with a 975 real identity via a cloud account, a credit card or other 976 information. 978 *RECOMMENDATION:* If stronger privacy guarantees are needed vis- 979 a-vis of the push notification provider, the client can choose to 980 periodically connect to the Delivery Service without the need of a 981 dedicated push notification infrastructure. 983 3.4. Authentication Service Compromise 985 The Authentication Service design is left to the infrastructure 986 designers. In most designs, a compromised AS is a serious matter, as 987 the AS can serve incorrect or attacker-provided identities to 988 clients. 990 -- The attacker can link an identity to a credential 992 -- The attacker can generate new credentials 994 -- The attacker can sign new credentials 996 -- The attacker can publish or distribute credentials 998 Infrastructures that provide cryptographic material or credentials in 999 place of the MLS client (which is under the control of the user) have 1000 often the ability to use the associated secrets to perform operations 1001 on behalf of the user, which is unacceptable in many situations. 1002 Other mechanisms can be used to prevent this issue, such as the 1003 service blessing cryptographic material used by an MLS client. 1005 *RECOMMENDATION:* Make clients submit signature public keys to the 1006 AS, this is usually better than the AS generating public key pairs 1007 because the AS cannot sign on behalf of the client. This is a 1008 benefit of a Public Key Infrastructure in the style of the 1009 Internet PKI. 1011 An attacker that can generate or sign new credential may or may not 1012 have access to the underlying cryptographic material necessary to 1013 perform such operations. In that last case, it results in windows of 1014 time for which all emitted credentials might be compromised. 1016 *RECOMMENDATION:* Using HSMs to store the root signature keys to 1017 limit the ability of an adversary with no physical access to 1018 extract the top-level signature key. 1020 3.4.1. Authentication compromise: Ghost users and impersonations 1022 One thing for which the MLS Protocol is designed for is to make sure 1023 that all clients know who is in the group at all times. This means 1024 that - if all Members of the group and the Authentication Service are 1025 honest - no other parties than the members of the current group can 1026 read and write messages protected by the protocol for that Group. 1028 Beware though, the link between the cryptographic identity of the 1029 Client and the real identity of the User is important. With some 1030 Authentication Service designs, a private or centralized authority 1031 can be trusted to generate or validate signature keypairs used in the 1032 MLS protocol. This is typically the case in some of the biggest 1033 messaging infrastructures. 1035 While this service is often very well protected from external 1036 attackers, it might be the case that this service is compromised. In 1037 such infrastructure, the AS could generate or validate a signature 1038 keypair for an identity which is not the expected one. Because a 1039 user can have many MLS clients running the MLS protocol, it possibly 1040 has many signature keypairs for multiple devices. 1042 In the case where an adversarial keypair is generated for a specific 1043 identity, an infrastructure without any transparency mechanism or 1044 out-of-band authentication mechanism could inject a malicious client 1045 into a group by impersonating a user. This is especially the case in 1046 large groups where the UI might not reflect all the changes back the 1047 the users. 1049 *RECOMMENDATION:* Make sure that MLS clients reflect all the 1050 membership changes to the users as they happen. If a choice has 1051 to be made because the number of notifications is too high, a 1052 public log should be maintained in the state of the device so that 1053 user can examine it. 1055 While the ways to handle MLS credentials are not defined by the 1056 protocol or the architecture documents, the MLS protocol has been 1057 designed with a mechanism that can be used to provide out-of-band 1058 authentication to users. The "authentication_secret" generated for 1059 each user at each epoch of the group is a one-time, per client, 1060 authentication secret which can be exchanged between users to prove 1061 their identity to each other. This can be done for instance using a 1062 QR code that can be scanned by the other parties. 1064 Another way to improve the security for the users is to provide a 1065 transparency mechanism which allows each user to check if credentials 1066 used in groups have been published in the transparency log. Another 1067 benefit of this mechanism is for revocation. The users of a group 1068 could check for revoked keys (in case of compromise detection) using 1069 a mechanism such as CRLite or some more advanced privacy preserving 1070 technology. 1072 *RECOMMENDATION:* Provide a Key Transparency and Out-of-Band 1073 authentication mechanisms to limit the impact of an Authentication 1074 Service compromise. 1076 We note, again, that as described prior to that section, the 1077 Authentication Service is facultative to design a working 1078 infrastructure and can be replaced by many mechanisms such as 1079 establishing prior one-to-one deniable channels, gossiping, or using 1080 TOFU for credentials used by the MLS Protocol. 1082 Another important consideration is the ease of redistributing new 1083 keys on client compromise, which helps recovering security faster in 1084 various cases. 1086 3.4.2. Privacy of the Group Membership 1088 Often, expectation from users is that the infrastructure will not 1089 retain the ability to constantly map the user identity to signature 1090 public keys of the MLS protocol. Some infrastructures will keep a 1091 mapping between signature public keys of clients and user identities. 1092 This can benefit an adversary that has compromised the AS (or 1093 required access according to regulation) the ability of monitoring 1094 unencrypted traffic and correlate the messages exchanged within the 1095 same group. 1097 *RECOMMENDATION:* Always use encrypted group operation messages to 1098 reduce issues related to privacy. 1100 In certain cases, the adversary can access to specific bindings 1101 between public keys and identities. If the signature keys are reused 1102 across groups, the adversary can get more information about the 1103 targeted user. 1105 *RECOMMENDATION:* Do not use the same signature keypair across 1106 groups. 1108 *RECOMMENDATION:* Separate the service binding the identities and 1109 the public keys from the service which generates or validates the 1110 credentials or cryptographic material of the Clients. 1112 3.5. Shared considerations regarding adversarial AS or DS services 1113 3.5.1. Privacy of the network connections 1115 There are many scenarios leading to communication between the 1116 application on a device and the Delivery Service or the 1117 Authentication Service. In particular when: 1119 * The application connects to the Authentication Service to generate 1120 or validate a new credential before distributing it. 1122 * The application fetches credentials at the Delivery Service prior 1123 to creating a messaging group (one-to-one or more than two 1124 clients). 1126 * The application fetches service provider information or messages 1127 on the Delivery Service. 1129 * The application sends service provider information or messages to 1130 the Delivery Service. 1132 In all these cases, the application will often connect to the device 1133 via a secure transport which leaks information about the origin of 1134 the request such as the IP address and depending on the protocol the 1135 MAC address of the device. 1137 Similar concern exist in the peer-to-peer use cases of MLS. 1139 *RECOMMENDATION:* In the case where privacy or anonymity is 1140 important, using adequate protection such as TOR or a VPN can 1141 improve metadata protection. 1143 More generally, using anonymous credential in an MLS based 1144 architecture might not be enough to provide strong privacy or 1145 anonymity properties. 1147 3.6. Client Compromise 1149 The MLS protocol adopts a threat model which includes multiple forms 1150 of Client compromises. While adversaries are in a very strong 1151 position if they have compromised an MLS client, there are still 1152 situations where security guarantees can be recovered thanks to the 1153 PCS properties achieved by the MLS protocol. 1155 In this section we will explore the consequences and recommendations 1156 regarding the following compromise scenarios: 1158 -- The attacker has access to a specific symmetric encryption key 1160 -- The attacker has access to the group secrets for one group 1161 -- The attacker has access to a signature oracle for any group 1163 -- The attacker has access to the signature key for one group 1165 -- The attacker has access to all secrets of a user for all groups 1166 (full state compromise) 1168 [[TODO: Cite the research papers in the context of these compromise 1169 models]] 1171 Recall that the MLS protocol provides chains of AEAD keys, per sender 1172 that are generated from Group Secrets. These keys are used to 1173 protect MLS Plaintext messages which can be Group Operation or 1174 Application messages. The Group Operation messages offer an 1175 additional protection as the secret exchanged within the TreeKEM 1176 group key agreement are public-key encrypted to subgroups with HPKE. 1178 3.6.1. Compromise of AEAD key material 1180 In some circumstances, adversaries may have access to specific AEAD 1181 keys and nonces which protect an Application or a Group Operation 1182 message. While this is a very weak kind of compromise, it can be 1183 realistic in cases of implementation vulnerabilities where only part 1184 of the memory leaks to the adversary. 1186 When an AEAD key is compromised, the adversary has access to a set of 1187 AEAD keys for the same chain and the same epoch, hence can decrypt 1188 messages sent using keys of this chain. An adversary cannot send a 1189 message to a group which appears to be from any valid client since 1190 they cannot forge the signature. 1192 The MLS protocol will ensure that an adversary cannot compute any 1193 previous AEAD keys for the same epoch, or any other epochs. Because 1194 of its Forward Secrecy guarantees, MLS will also retain secrecy of 1195 all other AEAD keys generated for _other_ MLS clients, outside this 1196 dedicated chain of AEAD keys and nonces, even within the epoch of the 1197 compromise. However the MLS protocol does not provide Post 1198 Compromise Secrecy for AEAD encryption within an epoch. This means 1199 that if the AEAD key of a chain is compromised, the adversary can 1200 compute an arbitrary number of subsequent AEAD keys for that chain. 1202 These guarantees are ensured by the structure of the MLS key schedule 1203 which provides Forward Secrecy for these AEAD encryptions, across the 1204 messages within the epoch and also across previous epochs. Those 1205 chains are completely disjoint and compromising keys across the 1206 chains would mean that some Group Secrets have been compromised, 1207 which is not the case in this attack scenario (we explore stronger 1208 compromise scenarios as part of the following sections). 1210 MLS provides Post-Compromise Secrecy against an active adaptative 1211 attacker across epochs for AEAD encryption, which means that as soon 1212 as the epoch is changed, if the attacker does not have access to more 1213 secret material they won't be able to access any protected messages 1214 from future epochs. 1216 In the case of an Application message, an AEAD key compromise means 1217 that the encrypted application message will be leaked as well as the 1218 signature over that message. This means, that the compromise has 1219 both confidentiality and privacy implications on the future AEAD 1220 encryptions of that chain. In the case of a Group Operation message, 1221 only the privacy is affected, as the signature is revealed, because 1222 the secrets themselves are protected by HPKE encryption. 1224 Note that under that compromise scenario, authentication is not 1225 affected in neither of these cases. As every member of the group can 1226 compute the AEAD keys for all the chains (they have access to the 1227 Group Secrets) in order to send and receive messages, the 1228 authentication provided by the AEAD encryption layer of the common 1229 framing mechanism is very weak. Successful decryption of an AEAD 1230 encrypted message only guarantees that a member of the group sent the 1231 message. 1233 3.6.2. Compromise of the Group Secrets of a single group for one or 1234 more group epochs 1236 The attack scenario considering an adversary gaining access to a set 1237 of Group secrets is significantly stronger. This can typically be 1238 the case when a member of the group is compromised. For this 1239 scenario, we consider that the signature keys are not compromised. 1240 This can be the case for instance if the adversary has access to part 1241 of the memory containing the group secrets but not to the signature 1242 keys which might be stored in a secure enclave. 1244 In this scenario, the adversary gains the ability to compute any 1245 number of AEAD encryption keys for any AEAD chains and can encrypt 1246 and decrypt all messages for the compromised epochs. 1248 If the adversary is passive, it is expected from the PCS properties 1249 of the MLS protocol that, as soon as an honest Commit message is sent 1250 by the compromised party, the next epochs will provide message 1251 secrecy. 1253 If the adversary is active, the adversary can follow the protocol and 1254 perform updates on behalf of the compromised party with no ability to 1255 an honest group to recover message secrecy. However, MLS provides 1256 PCS against active adaptative attackers through its Remove group 1257 operation. This means that, as long as other members of the group 1258 are honest, the protocol will guarantee message secrecy for all 1259 messages exchanged in the epochs after the compromised party has been 1260 removed. 1262 3.6.3. Compromise by an active adversary with the ability to sign 1263 messages 1265 Under such a scenario, where an active adversary has compromised an 1266 MLS client, two different settings emerge. In the strongest 1267 compromise scenario, the attacker has access to the signing key and 1268 can forge authenticated messages. In a weaker, yet realistic 1269 scenario, the attacker has compromised a client but the client 1270 signature keys are protected with dedicated hardware features which 1271 do not allow direct access to the value of the private key and 1272 instead provide a signature API. 1274 When considering an active adaptative attacker with access to a 1275 signature oracle, the compromise scenario implies a significant 1276 impact on both the secrecy and authentication guarantees of the 1277 protocol, especially if the attacker also has access to the group 1278 secrets. In that case both secrecy and authentication are broken. 1279 The attacker can generate any message, for the current and future 1280 epochs until an honest update from the compromised client happens. 1282 Note that under this compromise scenario, the attacker can perform 1283 all operations which are available to an legitimate client even 1284 without access to the actual value of the signature key. 1286 Without access to the group secrets, the adversary will not have the 1287 ability to generate messages which look valid to other members of the 1288 group and to the infrastructure as they need to have access to group 1289 secrets to compute the encryption keys or the membership tag. 1291 3.6.4. Compromise of the authentication with access to a signature key 1293 DISCLAIMER: Significant work remains in this section. [[TODO: Remove 1294 disclaimer.]] 1296 The difference between having access to the value of the signature 1297 key and only having access to a signing oracle is not about the 1298 ability of an active adaptative network attacker to perform different 1299 operations during the time of the compromise, the attacker can 1300 perform every operations available to a legitimate client in both 1301 cases. 1303 There is a significant difference, however in terms of recovery after 1304 a compromise. 1306 Because of the PCS guarantees provided by the MLS protocol, when a 1307 previously compromised client performs an honest Commit which is not 1308 under the control of the adversary, both secrecy and authentication 1309 of messages can be recovered in the case where the attacker didn't 1310 get access to the key. Because the adversary doesn't have the key 1311 and has lost the ability to sign messages, they cannot authenticate 1312 messages on behalf of the compromised party, even if they still have 1313 control over some group keys by colluding with other members of the 1314 group. 1316 This is in contrast with the case where the signature key is leaked. 1317 In that case PCS of the MLS protocol will eventually allow recovery 1318 of the authentication of messages for future epochs but only after 1319 compromised parties refresh their credentials securely. 1321 Beware that in both oracle and private key access, an active 1322 adaptative attacker, can follow the protocol and request to update 1323 its own credential. This in turn induce a signature key rotation 1324 which could provide the attacker with part or the full value of the 1325 private key depending on the architecture of the service provider. 1327 *RECOMMENDATION:* Signature private keys should be 1328 compartmentalized from other secrets and preferably protected by 1329 an HSM or dedicated hardware features to allow recovery of the 1330 authentication for future messages after a compromised. 1332 Even if the dedicated hardware approach is used, ideally, neither the 1333 Client or the Authentication service alone should provide the 1334 signature private key. Both should contribute to the key and it 1335 should be stored securely by the client with no direct access. 1337 3.6.5. Security consideration in the context of a full state compromise 1339 In real-world compromise scenarios, it is often the case that 1340 adversaries target specific devices to obtain parts of the memory or 1341 even the ability to execute arbitrary code in the targeted device. 1343 Also, recall that in this setting, the application will often retain 1344 the unencrypted messages. If so, the adversary does not have to 1345 break encryption at all to access sent and received messages. 1346 Messages may also be send by using the application to instruct the 1347 protocol implementation. 1349 *RECOMMENDATION:* If messages are stored on the device, they 1350 should be protected using encryption at rest, and the keys used 1351 should be stored securely using dedicated mechanisms on the 1352 device. 1354 *RECOMMENDATION:* If the threat model of the system is against an 1355 adversary which can access the messages on the device without even 1356 needing to attack MLS, the application should delete plaintext 1357 messages and ciphertexts immediately after encryption or 1358 decryption. 1360 Even though, from the strict point of view of the security 1361 formalization, a ciphertext is always public and will forever be, 1362 there is no loss in trying to erase ciphertexts as much as possible. 1364 Note that this document makes a clear distinction between the way 1365 signature keys and other group shared secrets must be handled. In 1366 particular, a large set of group secrets cannot necessarily assumed 1367 to be protected by an HSM or secure enclave features. This is 1368 especially true because these keys are extremely frequently used and 1369 changed with each message received by a client. 1371 However, the signature private keys are mostly used by clients to 1372 send a message. They also are providing the strong authentication 1373 guarantees to other clients, hence we consider that their protection 1374 by additional security mechanism should be a priority. 1376 Overall there is no way to detect or prevent these compromise, as 1377 discussed in the previous sections, performing separation of the 1378 application secret states can help recovery after compromise, this is 1379 the case for signature keys but similar concern exists for the 1380 encryption private key used in the TreeKEM Group Key Agreement. 1382 *RECOMMENDATION:* The secret keys used for public key encryption 1383 should be stored similarly to the way the signature keys are 1384 stored as key can be used to decrypt the group operation messages 1385 and contain the secret material used to compute all the group 1386 secrets. 1388 Even if secure enclaves are not perfectly secure, or even completely 1389 broken, adopting additional protections for these keys can ease 1390 recovery of the secrecy and authentication guarantees after a 1391 compromise where for instance, an attacker can sign messages without 1392 having access to the key. In certain contexts, the rotation of 1393 credentials might only be triggered by the AS through ACLs, hence be 1394 outside of the capabilities of the attacker. 1396 [[TODO: Considerations for Signature keys being reused or not across 1397 groups]] 1399 3.6.6. More attack scenarios 1401 [[TODO: Make examples for more complex attacks, cross groups, multi 1402 collusions...]] 1404 [[TODO: Do we discuss PCFS in this document? If yes, where?]] 1406 4. IANA Considerations 1408 This document makes no requests of IANA. 1410 5. Contributors 1412 * Katriel Cohn-Gordon 1414 University of Oxford 1416 me@katriel.co.uk 1418 * Cas Cremers 1420 University of Oxford 1422 cremers@cispa.de 1424 * Thyla van der Merwe 1426 Royal Holloway, University of London 1428 thyla.van.der@merwe.tech 1430 * Jon Millican 1432 Facebook 1434 jmillican@fb.com 1436 * Raphael Robert 1438 Wire 1440 raphael@wire.com 1442 6. Informative References 1444 [KeyTransparency] 1445 Google, ., "Key Transparency", 2017, 1446 . 1448 [MLSPROTO] Barnes, R., Beurdouche, B., Millican, J., Omara, E., Cohn- 1449 Gordon, K., and R. Robert, "Messaging Layer Security 1450 Protocol", 2018. 1452 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1453 Text on Security Considerations", BCP 72, RFC 3552, 1454 DOI 10.17487/RFC3552, July 2003, 1455 . 1457 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 1458 Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, 1459 March 2011, . 1461 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 1462 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 1463 October 2013, . 1465 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1466 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 1467 2014, . 1469 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1470 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1471 . 1473 Authors' Addresses 1475 Emad Omara 1476 Google 1478 Email: emadomara@google.com 1480 Benjamin Beurdouche 1481 Inria & Mozilla 1483 Email: benjamin.beurdouche@inria.fr 1485 Eric Rescorla 1486 Mozilla 1488 Email: ekr@rtfm.com 1490 Srinivas Inguva 1491 Twitter 1492 Email: singuva@twitter.com 1494 Albert Kwon 1495 MIT 1497 Email: kwonal@mit.edu 1499 Alan Duric 1500 Wire 1502 Email: alan@wire.com