idnits 2.17.00 (12 Aug 2021) /tmp/idnits12629/draft-ietf-mls-architecture-07.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 478: '...Delivery Service MUST enforce global c...' RFC 2119 keyword, line 525: '...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 (4 October 2021) is 222 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'KeyTransparency' is defined on line 1502, but no explicit reference was found in the text -- 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 (~~), 2 warnings (==), 3 comments (--). 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: 7 April 2022 Mozilla 6 E. Omara 7 Google 8 S. Inguva 9 Twitter 10 A. Kwon 11 MIT 12 A. Duric 13 Wire 14 4 October 2021 16 The Messaging Layer Security (MLS) Architecture 17 draft-ietf-mls-architecture-07 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 7 April 2022. 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.2.1. Credential Authentication . . . . . . . . . . . . . . 8 96 2.2.2. Message Authentication . . . . . . . . . . . . . . . 9 98 2.3. Delivery Service . . . . . . . . . . . . . . . . . . . . 9 99 2.3.1. Key Storage . . . . . . . . . . . . . . . . . . . . . 10 100 2.3.2. Key Retrieval . . . . . . . . . . . . . . . . . . . . 10 101 2.3.3. Delivery of messages and attachments . . . . . . . . 10 102 2.3.4. Membership knowledge . . . . . . . . . . . . . . . . 11 103 2.3.5. Membership and offline members . . . . . . . . . . . 12 104 2.4. Functional Requirements . . . . . . . . . . . . . . . . . 12 105 2.4.1. Membership Changes . . . . . . . . . . . . . . . . . 12 106 2.4.2. Parallel Groups . . . . . . . . . . . . . . . . . . . 13 107 2.4.3. Security of Attachments . . . . . . . . . . . . . . . 14 108 2.4.4. Asynchronous Usage . . . . . . . . . . . . . . . . . 14 109 2.4.5. Access Control . . . . . . . . . . . . . . . . . . . 14 110 2.4.6. Recovery After State Loss . . . . . . . . . . . . . . 15 111 2.4.7. Support for Multiple Devices . . . . . . . . . . . . 15 112 2.4.8. Extensibility / Pluggability . . . . . . . . . . . . 15 113 2.4.9. Federation . . . . . . . . . . . . . . . . . . . . . 16 114 2.4.10. Compatibility with Future Versions of MLS . . . . . . 16 115 3. Security and Privacy Considerations . . . . . . . . . . . . . 16 116 3.1. Assumptions on Transport Security Links . . . . . . . . . 17 117 3.1.1. Metadata Protection for Unencrypted Group 118 Operations . . . . . . . . . . . . . . . . . . . . . 17 119 3.1.2. DoS protection . . . . . . . . . . . . . . . . . . . 18 120 3.1.3. Message Suppression and Error Correction . . . . . . 18 121 3.2. Intended Security Guarantees . . . . . . . . . . . . . . 19 122 3.2.1. Message Secrecy and Authentication . . . . . . . . . 19 123 3.2.2. Forward and Post-Compromise Security . . . . . . . . 20 124 3.2.3. Non-Repudiation vs Deniability . . . . . . . . . . . 20 125 3.3. Endpoint Compromise . . . . . . . . . . . . . . . . . . . 21 126 3.3.1. Compromise of AEAD key material . . . . . . . . . . . 21 127 3.3.2. Compromise of the Group Secrets of a single group for 128 one or more group epochs . . . . . . . . . . . . . . 23 129 3.3.3. Compromise by an active adversary with the ability to 130 sign messages . . . . . . . . . . . . . . . . . . . . 23 131 3.3.4. Compromise of the authentication with access to a 132 signature key . . . . . . . . . . . . . . . . . . . . 24 133 3.3.5. Security consideration in the context of a full state 134 compromise . . . . . . . . . . . . . . . . . . . . . 25 135 3.3.6. More attack scenarios . . . . . . . . . . . . . . . . 26 136 3.4. Service Node Compromise . . . . . . . . . . . . . . . . . 26 137 3.4.1. General considerations . . . . . . . . . . . . . . . 26 138 3.4.2. Delivery Service Compromise . . . . . . . . . . . . . 27 139 3.4.3. Authentication Service Compromise . . . . . . . . . . 29 140 3.5. Considerations for attacks outside of the threat model . 31 141 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 142 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 32 143 6. Informative References . . . . . . . . . . . . . . . . . . . 33 144 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 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 DISCLAIMER: A lot of work is still ongoing on the current version of 157 this draft. Especially, this preliminary writing of the security 158 considerations has not been reviewed by the working group yet and 159 might contain errors. Please file an issue on the document's GitHub 160 if you find errors. 162 [[TODO: Remove disclaimer.]] 164 End-to-end security is a requirement for instant messaging systems 165 and is commonly deployed in many such systems. In this context, 166 "end-to-end" captures the notion that users of the system enjoy some 167 level of security -- with the precise level depending on the system 168 design -- even when the service provider they are using performs 169 unsatisfactorily. 171 Messaging Layer Security (MLS) specifies an architecture (this 172 document) and an abstract protocol [MLSPROTO] for providing end-to- 173 end security in this setting. MLS is not intended as a full instant 174 messaging protocol but rather is intended to be embedded in concrete 175 protocols, such as XMPP [RFC6120]. In addition, it does not specify 176 a complete wire encoding, but rather a set of abstract data 177 structures which can then be mapped onto a variety of concrete 178 encodings, such as TLS [RFC8446], CBOR [RFC7049], and JSON [RFC7159]. 179 Implementations which adopt compatible encodings will have some 180 degree of interoperability at the message level, though they may have 181 incompatible identity/authentication infrastructures. The MLS 182 protocol has been designed to provide the same security guarantees to 183 all users, for all group sizes, even when it reduces to only two 184 users. 186 2. General Setting 188 Informally, a group is a set of users who possibly use multiple 189 endpoint devices to interact with the Service Provider (SP). A group 190 may be as small as two members (the simple case of person to person 191 messaging) or as large as thousands. 193 In order to communicate securely, users initially interact with 194 services at their disposal to establish the necessary values and 195 credentials required for encryption and authentication. 197 The Service Provider presents two abstract functionalities that allow 198 clients to prepare for sending and receiving messages securely: 200 * An Authentication Service (AS) functionality which is responsible 201 for maintaining a binding between a unique identifier (identity) 202 and the public key material (credential) used for authentication 203 in the MLS protocol. This functionality must also be able to 204 generate these credentials or validate them if they are provided 205 by MLS clients. 207 * A Delivery Service (DS) functionality which can receive and 208 redistributing messages between group members. In the case of 209 group messaging, the delivery service may also be responsible for 210 acting as a "broadcaster" where the sender sends a single message 211 which is then forwarded to each recipient in the group by the DS. 212 The DS is also responsible for storing and delivering initial 213 public key material required by MLS clients in order to proceed 214 with the group secret key establishment that is part of the MLS 215 protocol. 217 For convenience, this document adopts the representation of these 218 services being standalone servers, however the MLS protocol design is 219 made so that it is not necessarily the case. 221 It is important to note that the Authentication Service functionality 222 can be completely abstract in the case of a Service Provider which 223 allows MLS clients to generate, redistribute and validate their 224 credentials themselves. 226 Similarly to the AS, the Delivery Service can be completely abstract 227 if users are able to distribute credentials and messages without 228 relying on a central Delivery Service. Note, though, that the MLS 229 protocol requires group operation messages to be processed in-order 230 by all MLS clients. 232 In some sense, a set of MLS clients which can achieve the AS and DS 233 functionalities without relying on an external party do not need a 234 Service Provider. 236 ---------------- -------------- 237 | Authentication | | Delivery | 238 | Service (AS) | | Service (DS) | 239 ---------------- -------------- 240 / | \ Group 241 / ************************************ 242 / * | \ * 243 ---------- * ---------- ---------- * 244 | Client 0 | * | Member 1 | | Member N | * 245 ---------- * ---------- ---------- * 246 ............ * ............ ............ * 247 User 0 * User 0 User 1 * 248 * * 249 ************************************ 251 In many systems, the AS and the DS are actually operated by the same 252 entity and may even be the same server. However, they are logically 253 distinct and, in other systems, may be operated by different 254 entities. Other partitions are also possible, such as having a 255 separate directory functionality or service. 257 According to this architecture design, a typical group messaging 258 scenario might look like this: 260 1. Alice, Bob and Charlie create accounts with a service provider 261 and obtain credentials from the AS. 263 2. Alice, Bob and Charlie authenticate to the DS and store some 264 initial keying material which can be used to send encrypted 265 messages to them for the first time. This keying material is 266 authenticated with their long term credentials. 268 3. When Alice wants to send a message to Bob and Charlie, she 269 contacts the DS and looks up their initial keying material. She 270 uses these keys to establish a new set of keys which she can use 271 to send encrypted messages to Bob and Charlie. She then sends 272 the encrypted message(s) to the DS, which forwards them to the 273 recipients. 275 4. Bob and/or Charlie respond to Alice's message. In addition, they 276 might choose to update their key material which provides post- 277 compromise security Section 3.2.2. As a consequence of that 278 change, the group secrets are updated 280 Clients may wish to do the following: 282 * create a group by inviting a set of other clients; 283 * add one or more clients to an existing group; 285 * remove one or more members from an existing group; 287 * update their own key material 289 * join an existing group; 291 * leave a group; 293 * send a message to everyone in the group; 295 * receive a message from someone in the group. 297 At the cryptographic level, clients (and by extension members in 298 groups) have equal permissions. For instance, any member can add or 299 remove another client in a group. This is in contrast to some 300 designs in which there is a single group controller who can modify 301 the group. MLS is compatible with having group administration 302 restricted to certain users, but we assume that those restrictions 303 are enforced by authentication and access control at the application 304 layer. 306 Thus, for instance, while the MLS protocol allows for any existing 307 member of a group to add a new client, applications which use MLS 308 might enforce additional restrictions for which only a subset of 309 members can qualify, and thus will handle enforcing group policies 310 (such as determining if a user is allowed to add new users to the 311 group) at the application level. 313 2.1. Group, Members and Clients 315 While informally, a group can be considered to be a set of users 316 possibly using multiple endpoint devices to interact with the Service 317 Provider, this definition is too simplistic. 319 Formally, a client is a set of cryptographic objects composed by 320 public values such as a name (an identity), a public encryption key 321 and a public signature key. Ownership of a client by a user is 322 determined by the fact that the user has knowledge of the associated 323 secret values. When a client is part of a Group, it is called a 324 Member and its signature key pair uniquely defines its identity to 325 other clients or members in the Group. In some messaging systems, 326 clients belonging to the same user must all share the same identity 327 key pair, but MLS does not assume this. 329 Users will typically own multiple clients, potentially one or more 330 per end-user devices (phones, web clients or other devices...) and 331 may choose to authenticate using the same signature key across 332 devices, using one signature key per device or even one signature key 333 per group. 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 2.2. Authentication Service 344 The Authentication Service (AS) has to provide two functionalities: 346 1. authenticate the credentials (i.e. the identity/signature 347 keypair) used in a group 349 2. authenticate messages sent in groups given the signature over the 350 message and the sending member's credential 352 The AS is considered an abstract layer by the MLS specification, part 353 of this service could be, for instance, running on the members' 354 devices, while another part is a separate entity entirely. 356 By the nature of its roles in MLS authentication, the AS is invested 357 with a large amount of trust and the compromise of one of its 358 functionalities could allow an adversary to, among other things, 359 impersonate group members. We discuss security considerations 360 regarding the compromise of the different AS functionalities in 361 detail in Section Section 3.4.3. 363 2.2.1. Credential Authentication 365 In many cases, the first functionality might be provided by a service 366 which fulfills a role similar to a certification authority in the 367 WebPKI: it provides a binding of an identity (e.g., a user name, 368 phone number, email address, etc) to a signature key. The identity/ 369 signature key pair can then either be used directly in a group, or as 370 an root of trust which in turn authenticates credentials used in the 371 group. 373 The flexibility afforded by the latter option allows for multiple 374 infrastructure considerations and has the benefit of providing ways 375 to use different signature keys across different groups by using 376 hierarchical authentication keys. This flexibility also comes at the 377 price of a security tradeoff, described in the security 378 considerations, between potential unlinkability of the signature keys 379 across groups and the amount of time required to reinstate 380 authentication and secrecy of messages after the compromise of a 381 device. 383 2.2.2. Message Authentication 385 MLS messages are authenticated by a signature conforming to the 386 signature scheme of the group's ciphersuite. To allow for message 387 deniability (see Section Section 3.2.3), messages are not required to 388 be signed by the private key corresponding to a member's credential, 389 but the key must be authenticated using some mechanism. Thus, 390 message authentication relies on the accuracy of the key's 391 authentication vice the credential authentication. 393 While credential authentication can be performed by a separate 394 entity, message authentication should be performed by each member 395 separately due to the encryption layer of the protocol which protects 396 the signature of the message. 398 2.3. Delivery Service 400 The Delivery Service (DS) is expected to play multiple roles in the 401 Service Provider architecture: 403 * To act as a directory service providing the initial keying 404 material for clients to use. This allows a client to establish a 405 shared key and send encrypted messages to other clients even if 406 the other client is offline. 408 * To route messages between clients and to act as a message 409 broadcaster, taking in one message and forwarding it to multiple 410 clients (also known as "server side fanout"). 412 Because the MLS protocol provides a way for clients to send and 413 receive application messages asynchronously, it only provides causal 414 ordering of application messages from senders while it has to enforce 415 global ordering of group operations to provide Group Agreement. 416 [[TODO: Casual ordering?]] 418 Depending on the level of trust given by the group to the Delivery 419 Service, the functional and privacy guarantees provided by MLS may 420 differ but the authentication and confidentiality guarantees remain 421 the same. 423 Unlike the Authentication Service which is trusted for authentication 424 and secrecy, the Delivery Service is completely untrusted regarding 425 this property. While privacy of group membership might be a problem 426 in the case of a Delivery Service server fanout, the Delivery Service 427 can be considered as an active, adaptive network attacker from the 428 point of view of the security analysis. 430 2.3.1. Key Storage 432 Upon joining the system, each client stores its initial cryptographic 433 key material with the Delivery Service. This key material, called a 434 KeyPackage, advertises the functional abilities of the client such as 435 supported protocol versions and extensions and the following 436 cryptographic information: 438 * A credential from the Authentication Service attesting to the 439 binding between the identity and the client's signature key. 441 * The client's asymmetric encryption public key material signed with 442 the signature public key associated with the credential. 444 As noted above, users may own multiple clients, each with their own 445 keying material, and thus there may be multiple entries stored by 446 each user. 448 The Delivery Service is also responsible for allowing users to add, 449 remove or update their initial key material, and for ensuring that 450 the identifier for these keys are unique across all keys stored on 451 the Delivery Service. 453 2.3.2. Key Retrieval 455 When a client wishes to establish a group, it first contacts the 456 Delivery Service to request a KeyPackage for each other client, 457 authenticates the KeyPackages using the signature keys, and then can 458 use those to form the group. 460 2.3.3. Delivery of messages and attachments 462 The main responsibility of the Delivery Service is to ensure delivery 463 of messages. Specifically, we assume that Delivery Services provide: 465 * Reliable delivery: when a message is provided to the Delivery 466 Service, it is eventually delivered to all clients. 468 * In-order delivery: messages are delivered to the group in the 469 order they are received by the Delivery Service and in 470 approximately the order in which they are sent by clients. The 471 latter is an approximate guarantee because multiple clients may 472 send messages at the same time and so the Delivery Service needs 473 some latitude in enforcing ordering across clients. 475 * Consistent ordering: the Delivery Service must ensure that all 476 clients have the same view of message ordering for 477 cryptographically relevant operations. This means that the 478 Delivery Service MUST enforce global consistency of the ordering 479 of group operation messages. 481 Note that the protocol provides three important pieces of information 482 within an MLSCiphertext message in order to provide ordering: 484 * The Group Identifier (GID) to allow for distinguishing the group 485 for which the message has been sent; 487 * The Epoch number, which represents the number of changes (version) 488 of the group associated with a specific GID, and allows for 489 lexicographical ordering of messages from different epochs within 490 the same group; 492 * The Content Type of the message, which allows the Delivery Service 493 to determine the ordering requirement on the message. 495 The MLS protocol itself can verify these properties. For instance, 496 if the Delivery Service reorders messages from a client or provides 497 different clients with inconsistent orderings, then clients can 498 detect this misconduct. However, the protocol relies on the 499 ordering, and on the fact that only one honest group operation 500 message is fanned-out to clients per Epoch, to provide clients with a 501 consistent view of the evolving Group State. 503 Note that some forms of Delivery Service misbehavior are still 504 possible and difficult to detect. For instance, a Delivery Service 505 can simply refuse to relay messages to and from a given client. 506 Without some sort of side information, other clients cannot generally 507 distinguish this form of Denial of Service (DoS) attack. 509 2.3.4. Membership knowledge 511 Group membership is itself sensitive information and MLS is designed 512 to drastically limit the amount of persistant metadata. However, 513 large groups often require an infrastructure which provides server 514 fanout. In the case of client fanout, the destinations of a message 515 is known by all clients, hence the server usually does not need this 516 information. However, they may learn this information through 517 traffic analysis. Unfortunately, in a server side fanout model, the 518 Delivery Service can learn that a given client is sending the same 519 message to a set of other clients. In addition, there may be 520 applications of MLS in which the group membership list is stored on 521 some server associated with the Delivery Service. 523 While this knowledge is not a break of authentication or 524 confidentiality, it is a serious issue for privacy. In the case 525 where metadata has to be persisted for functionality, it SHOULD be 526 stored encrypted at rest. 528 2.3.5. Membership and offline members 530 Because Forward Secrecy (FS) and Post-Compromise Security (PCS) rely 531 on the active deletion and replacement of keying material, any client 532 which is persistently offline may still be holding old keying 533 material and thus be a threat to both FS and PCS if it is later 534 compromised. 536 MLS cannot inherently defend against this problem, especially in the 537 case where the client has not processed messages, but MLS-using 538 systems can enforce some mechanism to try to retain these properties. 539 Typically this will consist of evicting clients which are idle for 540 too long, or mandate a silent key update from clients that is not 541 attached to other messaging traffic, thus containing the threat of 542 compromise. The precise details of such mechanisms are a matter of 543 local policy and beyond the scope of this document. 545 2.4. Functional Requirements 547 MLS is designed as a large scale group messaging protocol and hence 548 aims to provide performance and safety to its users. Messaging 549 systems that implement MLS provide support for conversations 550 involving two or more members, and aim to scale to groups as large as 551 50,000 members, typically including many users using multiple 552 devices. 554 2.4.1. Membership Changes 556 MLS aims to provide agreement on group membership, meaning that all 557 group members have agreed on the list of current group members. 559 Some applications may wish to enforce ACLs to limit addition or 560 removal of group members, to privileged clients or users. Others may 561 wish to require authorization from the current group members or a 562 subset thereof. Regardless, MLS does not allow for or support 563 addition or removal of group members without informing all other 564 members. 566 Once a client is part of a group, the set of devices controlled by 567 the user can only be altered by an authorized member of the group. 568 This authorization could depend on the application: some applications 569 might want to allow certain members of the group to add or remove 570 devices on behalf of another member, while other applications might 571 want a more strict policy and allow only the owner of the devices to 572 add or remove them at the potential cost of weaker PCS guarantees. 573 Application setup may also determine other forms of membership 574 validity, e.g. through an identity key alignment to the member with 575 separate signature keys per device. If a certificate chain is used 576 to sign off on device signature keys, then revocation by the owner 577 adds an alternative flag to prompt membership removal. 579 [[OPEN ISSUE: Above paragraph conflicts slightly under assumptions 580 about multiple device memberships vs. those described below under 581 "Support for Multiple Devices"]] 583 Members who are removed from a group do not enjoy special privileges: 584 compromise of a removed group member does not affect the security of 585 messages sent after their removal but might affect previous messages 586 if the group secrets have not been deleted properly. 588 2.4.2. Parallel Groups 590 Any user may have membership in several groups simultaneously. The 591 set of members of any group may or may not form a subset of the 592 members of another group. MLS guarantees that the FS and PCS goals 593 within a given group are maintained and not weakened by user 594 membership in multiple groups. However, actions in other groups 595 likewise do not strengthen the FS and PCS guarantees within a given 596 group, e.g. key updates within a given group following a device 597 compromise does not provide PCS healing in other groups; each group 598 must be updated separately to achieve internal goals. This also 599 applies to future groups that a member has yet to join, that are 600 likewise unaffected by updates performed in current groups. 602 Some applications may strengthen connectivity among parallel groups 603 by requiring periodic key updates from a user across all groups in 604 which they have membership, or using the PSK mechanism to link 605 healing properties among parallel groups. Such application choices 606 however are outside the scope of MLS. 608 2.4.3. Security of Attachments 610 The security properties expected for attachments in the MLS protocol 611 are very similar to the ones expected from messages. The distinction 612 between messages and attachments stems from the fact that the typical 613 average time between the download of a message and the one from the 614 attachments may be different. For many reasons (a typical reason 615 being the lack of high bandwidth network connectivity), the lifetime 616 of the cryptographic keys for attachments is usually higher than for 617 messages, hence slightly weakening the PCS guarantees for 618 attachments. 620 2.4.4. Asynchronous Usage 622 No operation in MLS requires two distinct clients or members to be 623 online simultaneously. In particular, members participating in 624 conversations protected using MLS can update shared keys, add or 625 remove new members, and send messages and attachments without waiting 626 for another user's reply. 628 Messaging systems that implement MLS have to provide a transport 629 layer for delivering messages asynchronously and reliably. 631 2.4.5. Access Control 633 The MLS protocol allows each member of the messaging group to perform 634 operations equally. This is because all clients within a group 635 (members) have access to the shared cryptographic material. However 636 every service/infrastructure has control over policies applied to its 637 own clients. Applications managing MLS clients can be configured to 638 allow for specific group operations. An application can, for 639 example, decide to provide specific permissions to a group 640 administrator that will be the one to perform add and remove 641 operations, but the flexibility is immense here. On the other hand, 642 in many settings such as open discussion forums, joining can be 643 allowed for anyone. 645 The MLS protocol can, in certain modes, exchange unencrypted group 646 operation messages. This flexibility is to allow services to perform 647 access control tasks on behalf of the group. 649 While the Application messages will always be encrypted, having the 650 handshake messages in plaintext has inconveniences in terms of 651 privacy as someone could collect the signatures on the handshake 652 messages and use them for tracking. 654 *RECOMMENDATION:* Prefer using encrypted group operation messages 655 to avoid privacy issues related to non-encrypted signatures. 657 Note that in the default case of encrypted handshake messages, the 658 application level must make sure that the access control policies are 659 consistent across all clients to make sure that they remain in sync. 660 If two different policies were applied, the clients might not accept 661 or reject a group operation and end-up in different cryptographic 662 states, breaking their ability to communicate. 664 *RECOMMENDATION:* Avoid using inconsistent access control policies 665 in the case of encrypted group operations. 667 2.4.6. Recovery After State Loss 669 Group members whose local MLS state is lost or corrupted can 670 reinitialize their state and continue participating in the group. 671 This does not provide the member with access to group messages from 672 during the state loss window, but enables proof of prior membership 673 in the group. Applications may choose various configurations for 674 providing lost messages to valid group members that are able to prove 675 prior membership. 677 [[OPEN ISSUE: The previous statement seems too strong, establish what 678 exact functional requirement we have regarding state recovery. 679 Previously: "This may entail some level of message loss, but does not 680 result in permanent exclusion from the group." -- Statement edited]] 682 2.4.7. Support for Multiple Devices 684 It is typically expected for users within a group to own various 685 devices. A new device can be added to a group and be considered as a 686 new client by the protocol. This client will not gain access to the 687 history even if it is owned by someone who owns another member of the 688 group. Restoring history is typically not allowed at the protocol 689 level but applications can elect to provide such a mechanism outside 690 of MLS. Such mechanisms, if used, may undermine the FS and PCS 691 guarantees provided by MLS. 693 2.4.8. Extensibility / Pluggability 695 Messages that do not affect the group state can carry an arbitrary 696 payload with the purpose of sharing that payload between group 697 members. No assumptions are made about the format of the payload. 699 2.4.9. Federation 701 The protocol aims to be compatible with federated environments. 702 While this document does not specify all necessary mechanisms 703 required for federation, multiple MLS implementations can 704 interoperate to form federated systems if they use compatible 705 authentication mechanisms, ciphersuites, and infrastructure 706 functionalities. 708 2.4.10. Compatibility with Future Versions of MLS 710 It is important that multiple versions of MLS be able to coexist in 711 the future. Thus, MLS offers a version negotiation mechanism; this 712 mechanism prevents version downgrade attacks where an attacker would 713 actively rewrite messages with a lower protocol version than the ones 714 originally offered by the endpoints. When multiple versions of MLS 715 are available, the negotiation protocol guarantees that the version 716 agreed upon will be the highest version supported in common by the 717 group. 719 In MLS 1.0, the creator of the group is responsible for selecting the 720 best ciphersuite supported across clients. Each client is able to 721 verify availability of protocol version, ciphersuites and extensions 722 at all times once he has at least received the first group operation 723 message. 725 3. Security and Privacy Considerations 727 MLS adopts the Internet threat model [RFC3552] and therefore assumes 728 that the attacker has complete control of the network. It is 729 intended to provide the security services described in the face of 730 such attackers. 732 -- The attacker can monitor the entire network. 734 -- The attacker can read unprotected messages. 736 -- The attacker can generate and inject any message in the 737 unprotected transport layer. 739 In addition, these guarantees are intended to degrade gracefully in 740 the presence of compromise of the transport security links as well as 741 of both clients and elements of the messaging system, as described in 742 the remainder of this section. 744 Generally, MLS is designed under the assumption that the transport 745 layer is present to protect metadata and privacy in general, while 746 the MLS protocol is providing stronger guarantees such as 747 confidentiality, integrity and authentication guarantees. Stronger 748 properties such as deniability can also be achieved in specific 749 architecture designs. 751 3.1. Assumptions on Transport Security Links 753 Any secure channel can be used as a transport layer to protect MLS 754 messages such as QUIC, TLS, WireGuard or TOR. However, the MLS 755 protocol is designed to consider the following threat-model: 757 -- The attacker can read and write arbitrary messages inside the 758 secure transport channel. 760 This departs from most threat models where we consider that the 761 secure channel used for transport always provides secrecy. The 762 reason for this consideration is that in the group setting, active 763 malicious insiders or adversarial services are to be considered. 765 3.1.1. Metadata Protection for Unencrypted Group Operations 767 The main use of the secure transport layer for MLS is to protect the 768 already limited amount of metadata. Very little information is 769 contained in the unencrypted header of the MLS protocol message 770 format for group operation messages, and application messages are 771 always encrypted in MLS. 773 Contrary to popular messaging services, the full list of recipients 774 cannot be sent to the server for dispatching messages because that 775 list is potentially extremely large in MLS. Therefore, the metadata 776 typically consists of a pseudo-random Group Identifier (GID), a 777 numerical index referring to the key needed to decrypt the ciphertext 778 content, and another numerical value to determine the epoch of the 779 group (the number of group operations that have been performed). 781 The MLS protocol provides an authenticated "Authenticated Additional 782 Data" field for applications to make data available outside the 783 MLSCiphertext. 785 *RECOMMENDATION:* Use the "Authenticated Additional Data" field of 786 the MLSCiphertext message instead of using other unauthenticated 787 means of sending metadata throughout the infrastructure. If the 788 data is private, the infrastructure should use encrypted 789 Application messages instead. 791 Even though some of this metadata information does not consist of 792 secret payloads, in correlation with other data a network observer 793 might be able to reconstruct sensitive information. Using a secure 794 channel to transfer this information will prevent a network attacker 795 to access this MLS protocol metadata if it cannot compromise the 796 secure channel. 798 More importantly, there is one specific case where having no secure 799 channel to exchange the MLS messages can have a serious impact on 800 privacy. In the case of unencrypted group operation messages, 801 observing the signatures of the group operation messages may lead an 802 adversary to extract information about the group memberships. 804 *RECOMMENDATION:* Never use the unencrypted mode for group 805 operations without using a secure channel for the transport layer. 807 3.1.2. DoS protection 809 In general we do not consider Denial of Service (DoS) resistance to 810 be the responsibility of the protocol. However, it should not be 811 possible for anyone aside from the Delivery Service to perform a 812 trivial DoS attack from which it is hard to recover. This can be 813 achieved through the secure transport layer. 815 In the centralized setting, DoS protection can typically be performed 816 by using tickets or cookies which identify users to a service for a 817 certain number of connections. Such a system helps in preventing 818 anonymous clients from sending arbitrary numbers of group operation 819 messages to the Delivery Service or the MLS clients. 821 *RECOMMENDATION:* Anonymous credentials can be used in order to 822 help DoS attacks prevention, in a privacy preserving manner. Note 823 that the privacy of these mechanisms has to be adjusted in 824 accordance with the privacy expected from the secure transport 825 links. (See more discussion further down.) 827 3.1.3. Message Suppression and Error Correction 829 The MLS protocol is particularly sensitive about group operation 830 message loss and reordering. This is because in the default setting, 831 MLS clients have to process those specific messages in order to have 832 a synchronized group state, after what the MLS protocol efficiently 833 generates keys for application messages. [[TODO: It is unclear from 834 this text whether MLS is "sensitive" in that it provides additional 835 constraints to prevent this, or is "sensitive" in that it is 836 vulnerable. Need to clarify]] 837 The Delivery Service can have the role of helping with reliability, 838 but is mainly useful for reliability in the asynchronous aspect of 839 the communication between MLS clients. 841 While it is difficult or impossible to prevent a network adversary 842 from suppressing payloads in transit, in certain infrastructures such 843 as banks or governments settings, unidirectional transports can be 844 used and be enforced via electronic or physical devices such as 845 diodes. This can lead to payload corruption which does not affect 846 the security or privacy properties of the MLS protocol but does 847 affect the reliability of the service. In that case specific 848 measures can be taken to ensure the appropriate level of redundancy 849 and quality of service for MLS. 851 *RECOMMENDATION:* If unidirectional transport is used for the 852 secure transport channel, prefer using a protocol which provides 853 Forward Error Correction. 855 3.2. Intended Security Guarantees 857 MLS aims to provide a number of security guarantees, covering 858 authentication, as well as confidentiality guarantees to different 859 degrees in different scenarios. 861 [[TODO: Authentication guarantees at the moment of joining a group 862 are interesting and I don't see a section where it would fit. I'm 863 thinking in particular about the parent hash and tree hashes in 864 combination with with signatures and the key schedule. I know that 865 several groups have worked on this and results are scattered between 866 a few papers. In particular, I think the guarantees for a member 867 being added to a new group are interesting.]] 869 3.2.1. Message Secrecy and Authentication 871 MLS enforces the encryption of application messages and thus 872 generally guarantees authentication and confidentiality of 873 application messages sent in a group. 875 In particular, this means that only other members of a given group 876 can decrypt the payload of a given application message, which 877 includes information about the sender of the message. 879 Similarly, group members receiving a message from another group 880 member can authenticate that group member as the sender of the 881 message and verify the message's integrity. 883 Message content can be deniable if the signature keys are exchanged 884 over a deniable channel prior to signing messages. 886 Depending on the group settings, handshake messages can be encrypted 887 as well. If that is the case, the same security guarantees apply. 889 MLS optionally allows the addition of padding to messages, mitigating 890 the amount of information leaked about the length of the plaintext to 891 an observer on the network. 893 3.2.2. Forward and Post-Compromise Security 895 MLS provides additional protection regarding secrecy of past messages 896 and future messages. These cryptographic security properties are 897 Forward Secrecy (FS) and Post-Compromise Security (PCS). 899 FS means that access to all encrypted traffic history combined with 900 an access to all current keying material on clients will not defeat 901 the secrecy properties of messages older than the oldest key of the 902 compromised client. Note that this means that clients have the 903 extremely important role of deleting appropriate keys as soon as they 904 have been used with the expected message, otherwise the secrecy of 905 the messages and the security for MLS is considerably weakened. 907 PCS means that if a group member's state is compromised at some time 908 t but the group member subsequently performs an update at some time 909 t', then all MLS guarantees apply to messages sent by the member 910 after time t', and by other members after they have processed the 911 update. For example, if an attacker learns all secrets known to 912 Alice at time t, including both Alice's long-term secret keys and all 913 shared group keys, but Alice performs a key update at time t', then 914 the attacker is unable to violate any of the MLS security properties 915 after the updates have been processed. 917 Both of these properties are satisfied even against compromised DSs 918 and ASs. 920 3.2.3. Non-Repudiation vs Deniability 922 MLS provides strong authentication within a group, such that a group 923 member cannot send a message that appears to be from another group 924 member. Additionally, some services require that a recipient be able 925 to prove to the service provider that a message was sent by a given 926 client, in order to report abuse. MLS supports both of these use 927 cases. In some deployments, these services are provided by 928 mechanisms which allow the receiver to prove a message's origin to a 929 third party (this if often called "non-repudiation"), but it should 930 also be possible to operate MLS in a "deniable" mode where such proof 931 is not possible. 933 3.3. Endpoint Compromise 935 The MLS protocol adopts a threat model which includes multiple forms 936 of endpoint/client compromise. While adversaries are in a very 937 strong position if they have compromised an MLS client, there are 938 still situations where security guarantees can be recovered thanks to 939 the PCS properties achieved by the MLS protocol. 941 In this section we will explore the consequences and recommendations 942 regarding the following compromise scenarios: 944 -- The attacker has access to a specific symmetric encryption key 946 -- The attacker has access to the group secrets for one group 948 -- The attacker has access to a signature oracle for any group 950 -- The attacker has access to the signature key for one group 952 -- The attacker has access to all secrets of a user for all groups 953 (full state compromise) 955 [[TODO: Cite the research papers in the context of these compromise 956 models]] 958 Recall that the MLS protocol provides chains of AEAD keys, per sender 959 that are generated from Group Secrets. These keys are used to 960 protect MLS Plaintext messages which can be Group Operation or 961 Application messages. The Group Operation messages offer an 962 additional protection as the secret exchanged within the TreeKEM 963 group key agreement are public-key encrypted to subgroups with HPKE. 965 3.3.1. Compromise of AEAD key material 967 In some circumstances, adversaries may have access to specific AEAD 968 keys and nonces which protect an Application or a Group Operation 969 message. While this is a very weak kind of compromise, it can be 970 realistic in cases of implementation vulnerabilities where only part 971 of the memory leaks to the adversary. 973 When an AEAD key is compromised, the adversary has access to a set of 974 AEAD keys for the same chain and the same epoch, hence can decrypt 975 messages sent using keys of this chain. An adversary cannot send a 976 message to a group which appears to be from any valid client since 977 they cannot forge the signature. 979 The MLS protocol will ensure that an adversary cannot compute any 980 previous AEAD keys for the same epoch, or any other epochs. Because 981 of its Forward Secrecy guarantees, MLS will also retain secrecy of 982 all other AEAD keys generated for _other_ MLS clients, outside this 983 dedicated chain of AEAD keys and nonces, even within the epoch of the 984 compromise. However the MLS protocol does not provide Post 985 Compromise Secrecy for AEAD encryption within an epoch. This means 986 that if the AEAD key of a chain is compromised, the adversary can 987 compute an arbitrary number of subsequent AEAD keys for that chain. 989 These guarantees are ensured by the structure of the MLS key schedule 990 which provides Forward Secrecy for these AEAD encryptions, across the 991 messages within the epoch and also across previous epochs. Those 992 chains are completely disjoint and compromising keys across the 993 chains would mean that some Group Secrets have been compromised, 994 which is not the case in this attack scenario (we explore stronger 995 compromise scenarios as part of the following sections). 997 MLS provides Post-Compromise Secrecy against an active adaptative 998 attacker across epochs for AEAD encryption, which means that as soon 999 as the epoch is changed, if the attacker does not have access to more 1000 secret material they won't be able to access any protected messages 1001 from future epochs. 1003 In the case of an Application message, an AEAD key compromise means 1004 that the encrypted application message will be leaked as well as the 1005 signature over that message. This means, that the compromise has 1006 both confidentiality and privacy implications on the future AEAD 1007 encryptions of that chain. In the case of a Group Operation message, 1008 only the privacy is affected, as the signature is revealed, because 1009 the secrets themselves are protected by HPKE encryption. 1011 Note that under that compromise scenario, authentication is not 1012 affected in neither of these cases. As every member of the group can 1013 compute the AEAD keys for all the chains (they have access to the 1014 Group Secrets) in order to send and receive messages, the 1015 authentication provided by the AEAD encryption layer of the common 1016 framing mechanism is very weak. Successful decryption of an AEAD 1017 encrypted message only guarantees that a member of the group sent the 1018 message. 1020 3.3.2. Compromise of the Group Secrets of a single group for one or 1021 more group epochs 1023 The attack scenario considering an adversary gaining access to a set 1024 of Group secrets is significantly stronger. This can typically be 1025 the case when a member of the group is compromised. For this 1026 scenario, we consider that the signature keys are not compromised. 1027 This can be the case for instance if the adversary has access to part 1028 of the memory containing the group secrets but not to the signature 1029 keys which might be stored in a secure enclave. 1031 In this scenario, the adversary gains the ability to compute any 1032 number of AEAD encryption keys for any AEAD chains and can encrypt 1033 and decrypt all messages for the compromised epochs. 1035 If the adversary is passive, it is expected from the PCS properties 1036 of the MLS protocol that, as soon as an honest Commit message is sent 1037 by the compromised party, the next epochs will provide message 1038 secrecy. 1040 If the adversary is active, the adversary can follow the protocol and 1041 perform updates on behalf of the compromised party with no ability to 1042 an honest group to recover message secrecy. However, MLS provides 1043 PCS against active adaptative attackers through its Remove group 1044 operation. This means that, as long as other members of the group 1045 are honest, the protocol will guarantee message secrecy for all 1046 messages exchanged in the epochs after the compromised party has been 1047 removed. 1049 3.3.3. Compromise by an active adversary with the ability to sign 1050 messages 1052 Under such a scenario, where an active adversary has compromised an 1053 MLS client, two different settings emerge. In the strongest 1054 compromise scenario, the attacker has access to the signing key and 1055 can forge authenticated messages. In a weaker, yet realistic 1056 scenario, the attacker has compromised a client but the client 1057 signature keys are protected with dedicated hardware features which 1058 do not allow direct access to the value of the private key and 1059 instead provide a signature API. 1061 When considering an active adaptative attacker with access to a 1062 signature oracle, the compromise scenario implies a significant 1063 impact on both the secrecy and authentication guarantees of the 1064 protocol, especially if the attacker also has access to the group 1065 secrets. In that case both secrecy and authentication are broken. 1066 The attacker can generate any message, for the current and future 1067 epochs until an honest update from the compromised client happens. 1069 Note that under this compromise scenario, the attacker can perform 1070 all operations which are available to an legitimate client even 1071 without access to the actual value of the signature key. 1073 Without access to the group secrets, the adversary will not have the 1074 ability to generate messages which look valid to other members of the 1075 group and to the infrastructure as they need to have access to group 1076 secrets to compute the encryption keys or the membership tag. 1078 3.3.4. Compromise of the authentication with access to a signature key 1080 DISCLAIMER: Significant work remains in this section. [[TODO: Remove 1081 disclaimer.]] 1083 The difference between having access to the value of the signature 1084 key and only having access to a signing oracle is not about the 1085 ability of an active adaptative network attacker to perform different 1086 operations during the time of the compromise, the attacker can 1087 perform every operations available to a legitimate client in both 1088 cases. 1090 There is a significant difference, however in terms of recovery after 1091 a compromise. 1093 Because of the PCS guarantees provided by the MLS protocol, when a 1094 previously compromised client performs an honest Commit which is not 1095 under the control of the adversary, both secrecy and authentication 1096 of messages can be recovered in the case where the attacker didn't 1097 get access to the key. Because the adversary doesn't have the key 1098 and has lost the ability to sign messages, they cannot authenticate 1099 messages on behalf of the compromised party, even if they still have 1100 control over some group keys by colluding with other members of the 1101 group. 1103 This is in contrast with the case where the signature key is leaked. 1104 In that case PCS of the MLS protocol will eventually allow recovery 1105 of the authentication of messages for future epochs but only after 1106 compromised parties refresh their credentials securely. 1108 Beware that in both oracle and private key access, an active 1109 adaptative attacker, can follow the protocol and request to update 1110 its own credential. This in turn induce a signature key rotation 1111 which could provide the attacker with part or the full value of the 1112 private key depending on the architecture of the service provider. 1114 *RECOMMENDATION:* Signature private keys should be 1115 compartmentalized from other secrets and preferably protected by 1116 an HSM or dedicated hardware features to allow recovery of the 1117 authentication for future messages after a compromised. 1119 Even if the dedicated hardware approach is used, ideally, neither the 1120 Client or the Authentication service alone should provide the 1121 signature private key. Both should contribute to the key and it 1122 should be stored securely by the client with no direct access. 1124 3.3.5. Security consideration in the context of a full state compromise 1126 In real-world compromise scenarios, it is often the case that 1127 adversaries target specific devices to obtain parts of the memory or 1128 even the ability to execute arbitrary code in the targeted device. 1130 Also, recall that in this setting, the application will often retain 1131 the unencrypted messages. If so, the adversary does not have to 1132 break encryption at all to access sent and received messages. 1133 Messages may also be send by using the application to instruct the 1134 protocol implementation. 1136 *RECOMMENDATION:* If messages are stored on the device, they 1137 should be protected using encryption at rest, and the keys used 1138 should be stored securely using dedicated mechanisms on the 1139 device. 1141 *RECOMMENDATION:* If the threat model of the system is against an 1142 adversary which can access the messages on the device without even 1143 needing to attack MLS, the application should delete plaintext 1144 messages and ciphertexts immediately after encryption or 1145 decryption. 1147 Even though, from the strict point of view of the security 1148 formalization, a ciphertext is always public and will forever be, 1149 there is no loss in trying to erase ciphertexts as much as possible. 1151 Note that this document makes a clear distinction between the way 1152 signature keys and other group shared secrets must be handled. In 1153 particular, a large set of group secrets cannot necessarily assumed 1154 to be protected by an HSM or secure enclave features. This is 1155 especially true because these keys are extremely frequently used and 1156 changed with each message received by a client. 1158 However, the signature private keys are mostly used by clients to 1159 send a message. They also are providing the strong authentication 1160 guarantees to other clients, hence we consider that their protection 1161 by additional security mechanism should be a priority. 1163 Overall there is no way to detect or prevent these compromise, as 1164 discussed in the previous sections, performing separation of the 1165 application secret states can help recovery after compromise, this is 1166 the case for signature keys but similar concern exists for the 1167 encryption private key used in the TreeKEM Group Key Agreement. 1169 *RECOMMENDATION:* The secret keys used for public key encryption 1170 should be stored similarly to the way the signature keys are 1171 stored as key can be used to decrypt the group operation messages 1172 and contain the secret material used to compute all the group 1173 secrets. 1175 Even if secure enclaves are not perfectly secure, or even completely 1176 broken, adopting additional protections for these keys can ease 1177 recovery of the secrecy and authentication guarantees after a 1178 compromise where for instance, an attacker can sign messages without 1179 having access to the key. In certain contexts, the rotation of 1180 credentials might only be triggered by the AS through ACLs, hence be 1181 outside of the capabilities of the attacker. 1183 [[TODO: Considerations for Signature keys being :reused or not across 1184 groups]] 1186 3.3.6. More attack scenarios 1188 [[TODO: Make examples for more complex attacks, cross groups, multi 1189 collusions...]] 1191 [[TODO: Do we discuss PCFS in this document? If yes, where?]] 1193 3.4. Service Node Compromise 1195 3.4.1. General considerations 1197 3.4.1.1. Privacy of the network connections 1199 There are many scenarios leading to communication between the 1200 application on a device and the Delivery Service or the 1201 Authentication Service. In particular when: 1203 * The application connects to the Authentication Service to generate 1204 or validate a new credential before distributing it. 1206 * The application fetches credentials at the Delivery Service prior 1207 to creating a messaging group (one-to-one or more than two 1208 clients). 1210 * The application fetches service provider information or messages 1211 on the Delivery Service. 1213 * The application sends service provider information or messages to 1214 the Delivery Service. 1216 In all these cases, the application will often connect to the device 1217 via a secure transport which leaks information about the origin of 1218 the request such as the IP address and depending on the protocol the 1219 MAC address of the device. 1221 Similar concerns exist in the peer-to-peer use cases of MLS. 1223 *RECOMMENDATION:* In the case where privacy or anonymity is 1224 important, using adequate protection such as TOR or a VPN can 1225 improve metadata protection. 1227 More generally, using anonymous credential in an MLS based 1228 architecture might not be enough to provide strong privacy or 1229 anonymity properties. 1231 3.4.2. Delivery Service Compromise 1233 MLS is intended to provide strong guarantees in the face of 1234 compromise of the DS. Even a totally compromised DS should not be 1235 able to read messages or inject messages that will be acceptable to 1236 legitimate clients. It should also not be able to undetectably 1237 remove, reorder or replay messages. 1239 However, a DS can mount a variety of DoS attacks on the system, 1240 including total DoS attacks (where it simply refuses to forward any 1241 messages) and partial DoS attacks (where it refuses to forward 1242 messages to and from specific clients). As noted in Section 2.3.3, 1243 these attacks are only partially detectable by clients without an 1244 out-of-band channel. Ultimately, failure of the DS to provide 1245 reasonable service must be dealt with as a customer service matter, 1246 not via technology. 1248 Because the DS is responsible for providing the initial keying 1249 material to clients, it can provide stale keys. This does not 1250 inherently lead to compromise of the message stream, but does allow 1251 it to attack forward security to a limited extent. This threat can 1252 be mitigated by having initial keys expire. 1254 3.4.2.1. Privacy of delivery and push notifications 1256 An important mechanism that is often ignored from the privacy 1257 considerations are the push-tokens. In many modern messaging 1258 architectures, applications are using push notification mechanisms 1259 typically provided by OS vendors. This is to make sure that when 1260 messages are available at the Delivery Service (or by other 1261 mechanisms if the DS is not a central server), the recipient 1262 application on a device knows about it. Sometimes the push 1263 notification can contain the application message itself which saves a 1264 round trip with the DS. 1266 To "push" this information to the device, the service provider and 1267 the OS infrastructures use unique per-device, per-application 1268 identifiers called push-tokens. This means that the push 1269 notification provider and the service provider have information on 1270 which devices receive information and at which point in time. 1272 Even though they can't necessarily access the content, which is 1273 typically encrypted MLS messages, the service provider and the push 1274 notification provider have to be trusted to avoid making correlation 1275 on which devices are recipients of the same message. 1277 For secure messaging systems, push notification are often sent real- 1278 time as it is not acceptable to create artificial delays for message 1279 retrieval. 1281 *RECOMMENDATION:* If real time notification are not necessary and 1282 that specific steps must be taken to improve privacy, one can 1283 delay notifications randomly across recipient devices using a 1284 mixnet or other techniques. 1286 Note that it is quite easy for legal requests to ask the service 1287 provider for the push-token associated to an identifier and perform a 1288 second request to the company operating the push-notification system 1289 to get information about the device, which is often linked with a 1290 real identity via a cloud account, a credit card or other 1291 information. 1293 *RECOMMENDATION:* If stronger privacy guarantees are needed vis- 1294 a-vis of the push notification provider, the client can choose to 1295 periodically connect to the Delivery Service without the need of a 1296 dedicated push notification infrastructure. 1298 3.4.3. Authentication Service Compromise 1300 The Authentication Service design is left to the infrastructure 1301 designers. In most designs, a compromised AS is a serious matter, as 1302 the AS can serve incorrect or attacker-provided identities to 1303 clients. 1305 -- The attacker can link an identity to a credential 1307 -- The attacker can generate new credentials 1309 -- The attacker can sign new credentials 1311 -- The attacker can publish or distribute credentials 1313 Infrastructures that provide cryptographic material or credentials in 1314 place of the MLS client (which is under the control of the user) have 1315 often the ability to use the associated secrets to perform operations 1316 on behalf of the user, which is unacceptable in many situations. 1317 Other mechanisms can be used to prevent this issue, such as the 1318 service blessing cryptographic material used by an MLS client. 1320 *RECOMMENDATION:* Make clients submit signature public keys to the 1321 AS, this is usually better than the AS generating public key pairs 1322 because the AS cannot sign on behalf of the client. This is a 1323 benefit of a Public Key Infrastructure in the style of the 1324 Internet PKI. 1326 An attacker that can generate or sign new credential may or may not 1327 have access to the underlying cryptographic material necessary to 1328 perform such operations. In that last case, it results in windows of 1329 time for which all emitted credentials might be compromised. 1331 *RECOMMENDATION:* Using HSMs to store the root signature keys to 1332 limit the ability of an adversary with no physical access to 1333 extract the top-level signature key. 1335 3.4.3.1. Authentication compromise: Ghost users and impersonations 1337 One thing for which the MLS Protocol is designed for is to make sure 1338 that all clients know who is in the group at all times. This means 1339 that - if all Members of the group and the Authentication Service are 1340 honest - no other parties than the members of the current group can 1341 read and write messages protected by the protocol for that Group. 1343 Beware though, the link between the cryptographic identity of the 1344 Client and the real identity of the User is important. With some 1345 Authentication Service designs, a private or centralized authority 1346 can be trusted to generate or validate signature keypairs used in the 1347 MLS protocol. This is typically the case in some of the biggest 1348 messaging infrastructures. 1350 While this service is often very well protected from external 1351 attackers, it might be the case that this service is compromised. In 1352 such infrastructure, the AS could generate or validate a signature 1353 keypair for an identity which is not the expected one. Because a 1354 user can have many MLS clients running the MLS protocol, it possibly 1355 has many signature keypairs for multiple devices. 1357 In the case where an adversarial keypair is generated for a specific 1358 identity, an infrastructure without any transparency mechanism or 1359 out-of-band authentication mechanism could inject a malicious client 1360 into a group by impersonating a user. This is especially the case in 1361 large groups where the UI might not reflect all the changes back the 1362 the users. 1364 *RECOMMENDATION:* Make sure that MLS clients reflect all the 1365 membership changes to the users as they happen. If a choice has 1366 to be made because the number of notifications is too high, a 1367 public log should be maintained in the state of the device so that 1368 user can examine it. 1370 While the ways to handle MLS credentials are not defined by the 1371 protocol or the architecture documents, the MLS protocol has been 1372 designed with a mechanism that can be used to provide out-of-band 1373 authentication to users. The "authentication_secret" generated for 1374 each user at each epoch of the group is a one-time, per client, 1375 authentication secret which can be exchanged between users to prove 1376 their identity to each other. This can be done for instance using a 1377 QR code that can be scanned by the other parties. 1379 Another way to improve the security for the users is to provide a 1380 transparency mechanism which allows each user to check if credentials 1381 used in groups have been published in the transparency log. Another 1382 benefit of this mechanism is for revocation. The users of a group 1383 could check for revoked keys (in case of compromise detection) using 1384 a mechanism such as CRLite or some more advanced privacy preserving 1385 technology. 1387 *RECOMMENDATION:* Provide a Key Transparency and Out-of-Band 1388 authentication mechanisms to limit the impact of an Authentication 1389 Service compromise. 1391 We note, again, that as described prior to that section, the 1392 Authentication Service is facultative to design a working 1393 infrastructure and can be replaced by many mechanisms such as 1394 establishing prior one-to-one deniable channels, gossiping, or using 1395 TOFU for credentials used by the MLS Protocol. 1397 Another important consideration is the ease of redistributing new 1398 keys on client compromise, which helps recovering security faster in 1399 various cases. 1401 3.4.3.2. Privacy of the Group Membership 1403 Often, expectation from users is that the infrastructure will not 1404 retain the ability to constantly map the user identity to signature 1405 public keys of the MLS protocol. Some infrastructures will keep a 1406 mapping between signature public keys of clients and user identities. 1407 This can benefit an adversary that has compromised the AS (or 1408 required access according to regulation) the ability of monitoring 1409 unencrypted traffic and correlate the messages exchanged within the 1410 same group. 1412 *RECOMMENDATION:* Always use encrypted group operation messages to 1413 reduce issues related to privacy. 1415 In certain cases, the adversary can access to specific bindings 1416 between public keys and identities. If the signature keys are reused 1417 across groups, the adversary can get more information about the 1418 targeted user. 1420 *RECOMMENDATION:* Do not use the same signature keypair across 1421 groups. 1423 *RECOMMENDATION:* Separate the service binding the identities and 1424 the public keys from the service which generates or validates the 1425 credentials or cryptographic material of the Clients. 1427 3.5. Considerations for attacks outside of the threat model 1429 Physical attacks on devices storing and executing MLS principals are 1430 not considered in depth in the threat model of the MLS protocol. 1431 While non-permanent, non-invasive attacks can sometime be equivalent 1432 to software attacks, physical attacks are considered outside of the 1433 MLS threat model. 1435 Compromise scenarios, typically consist in a software adversary, 1436 which can maintain active adaptative compromise and arbitrarily 1437 change the behavior of the client or service. 1439 On the other hand, security goals consider that honest clients will 1440 always run the protocol according to its specification. This relies 1441 on implementations of the protocol to securely implement the 1442 specification, which remains non-trivial. 1444 *RECOMMENDATION:* Additional steps should be taken to protect the 1445 device and the MLS clients from physical compromise. In such 1446 setting, HSMs and secure enclaves can be used to protect signature 1447 keys. 1449 More information will be available in the Server-Assist draft. 1451 [[TODO: Reference to server assist when the draft is available.]] 1453 4. IANA Considerations 1455 This document makes no requests of IANA. 1457 5. Contributors 1459 * Katriel Cohn-Gordon 1461 University of Oxford 1463 me@katriel.co.uk 1465 * Cas Cremers 1467 CISPA Helmholtz Center for Information Security 1469 cremers@cispa.de 1471 * Britta Hale 1473 Naval Postgraduate School 1475 britta.hale@nps.edu 1477 * Konrad Kohbrok 1479 Wire 1481 konrad@wire.com 1483 * Thyla van der Merwe 1485 Royal Holloway, University of London 1486 thyla.van.der@merwe.tech 1488 * Jon Millican 1490 Facebook 1492 jmillican@fb.com 1494 * Raphael Robert 1496 Wire 1498 raphael@wire.com 1500 6. Informative References 1502 [KeyTransparency] 1503 Google, ., "Key Transparency", 2017, 1504 . 1506 [MLSPROTO] Barnes, R., Beurdouche, B., Millican, J., Omara, E., Cohn- 1507 Gordon, K., and R. Robert, "Messaging Layer Security 1508 Protocol", 2018. 1510 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1511 Text on Security Considerations", BCP 72, RFC 3552, 1512 DOI 10.17487/RFC3552, July 2003, 1513 . 1515 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 1516 Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, 1517 March 2011, . 1519 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 1520 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 1521 October 2013, . 1523 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1524 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 1525 2014, . 1527 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1528 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1529 . 1531 Authors' Addresses 1532 Benjamin Beurdouche 1533 Inria & Mozilla 1535 Email: ietf@beurdouche.com 1537 Eric Rescorla 1538 Mozilla 1540 Email: ekr@rtfm.com 1542 Emad Omara 1543 Google 1545 Email: emadomara@google.com 1547 Srinivas Inguva 1548 Twitter 1550 Email: singuva@twitter.com 1552 Albert Kwon 1553 MIT 1555 Email: kwonal@mit.edu 1557 Alan Duric 1558 Wire 1560 Email: alan@wire.com