idnits 2.17.1 draft-ietf-mls-architecture-05.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 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 395: '... means that the DS MUST enforce global...' RFC 2119 keyword, line 441: '...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 (26 July 2020) is 1370 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: 1 error (**), 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: 27 January 2021 INRIA 6 E. Rescorla 7 Mozilla 8 S. Inguva 9 Twitter 10 A. Kwon 11 MIT 12 A. Duric 13 Wire 14 26 July 2020 16 The Messaging Layer Security (MLS) Architecture 17 draft-ietf-mls-architecture-05 19 Abstract 21 This document describes the reference architecture, functional and 22 security requirements for the Messaging Layer Security (MLS) 23 protocol. MLS provides a security layer for group messaging 24 applications, where the number of clients ranges from two to many. 25 It is meant to protect against eavesdropping, tampering, and message 26 forgery. 28 Discussion Venues 30 This note is to be removed before publishing as an RFC. 32 Source for this draft and an issue tracker can be found at 33 https://github.com/mlswg/mls-architecture. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on 27 January 2021. 51 Copyright Notice 53 Copyright (c) 2020 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 58 license-info) in effect on the date of publication of this document. 59 Please review these documents carefully, as they describe your rights 60 and restrictions with respect to this document. Code Components 61 extracted from this document must include Simplified BSD License text 62 as described in Section 4.e of the Trust Legal Provisions and are 63 provided without warranty as described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. General Setting . . . . . . . . . . . . . . . . . . . . . . . 3 69 2.1. Group, Members and Clients . . . . . . . . . . . . . . . 6 70 2.2. Authentication Service . . . . . . . . . . . . . . . . . 6 71 2.3. Delivery Service . . . . . . . . . . . . . . . . . . . . 7 72 2.3.1. Key Storage . . . . . . . . . . . . . . . . . . . . . 8 73 2.3.2. Key Retrieval . . . . . . . . . . . . . . . . . . . . 8 74 2.3.3. Delivery of messages and attachments . . . . . . . . 9 75 2.3.4. Membership knowledge . . . . . . . . . . . . . . . . 10 76 2.3.5. Membership and offline members . . . . . . . . . . . 10 77 3. System Requirements . . . . . . . . . . . . . . . . . . . . . 10 78 3.1. Functional Requirements . . . . . . . . . . . . . . . . . 10 79 3.1.1. Asynchronous Usage . . . . . . . . . . . . . . . . . 11 80 3.1.2. Recovery After State Loss . . . . . . . . . . . . . . 11 81 3.1.3. Support for Multiple Devices . . . . . . . . . . . . 11 82 3.1.4. Extensibility / Pluggability . . . . . . . . . . . . 11 83 3.1.5. Privacy . . . . . . . . . . . . . . . . . . . . . . . 12 84 3.1.6. Federation . . . . . . . . . . . . . . . . . . . . . 12 85 3.1.7. Compatibility with future versions of MLS . . . . . . 12 86 3.2. Security Requirements . . . . . . . . . . . . . . . . . . 12 87 3.2.1. Connections between Clients and Servers 88 (one-to-one) . . . . . . . . . . . . . . . . . . . . 13 89 3.2.2. Message Secrecy and Authentication . . . . . . . . . 13 90 4. Security Considerations . . . . . . . . . . . . . . . . . . . 16 91 4.1. Transport Security Links . . . . . . . . . . . . . . . . 16 92 4.2. Delivery Service Compromise . . . . . . . . . . . . . . . 16 93 4.3. Authentication Service Compromise . . . . . . . . . . . . 16 94 4.4. Client Compromise . . . . . . . . . . . . . . . . . . . . 17 95 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 96 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 97 7. Informative References . . . . . . . . . . . . . . . . . . . 18 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 100 1. Introduction 102 RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH 104 The source for this draft is maintained in GitHub. Suggested changes 105 should be submitted as pull requests at https://github.com/mlswg/mls- 106 architecture. Instructions are on that page as well. Editorial 107 changes can be managed in GitHub, but any substantive change should 108 be discussed on the MLS mailing list. 110 End-to-end security is a requirement for instant messaging systems 111 and is commonly deployed in many such systems. In this context, 112 "end-to-end" captures the notion that users of the system enjoy some 113 level of security - with the precise level depending on the system 114 design - even when the service provider they are using performs 115 unsatisfactorily. 117 Messaging Layer Security (MLS) specifies an architecture (this 118 document) and an abstract protocol [MLSPROTO] for providing end-to- 119 end security in this setting. MLS is not intended as a full instant 120 messaging protocol but rather is intended to be embedded in a 121 concrete protocol such as XMPP [RFC6120]. In addition, it does not 122 specify a complete wire encoding, but rather a set of abstract data 123 structures which can then be mapped onto a variety of concrete 124 encodings, such as TLS [RFC8446], CBOR [RFC7049], and JSON [RFC7159]. 125 Implementations which adopt compatible encodings will have some 126 degree of interoperability at the message level, though they may have 127 incompatible identity/authentication infrastructures. The MLS 128 protocol has been designed to provide the same security guarantees to 129 all users, for all group sizes, even when it reduces to only two 130 users. 132 This document is intended to describe the overall messaging system 133 architecture which the MLS protocol fits into, including the 134 operational requirements needed to achieve a functional system, and 135 to describe the security goals it is intended to fulfill. 137 2. General Setting 139 Informally, a group is a set of users who possibly use multiple 140 endpoint devices to interact with the Service Provider (SP). A group 141 may be as small as two members (the simple case of person to person 142 messaging) or as large as thousands. 144 In order to communicate securely, users initially interact with 145 services at their disposal to establish the necessary values and 146 credentials required for encryption and authentication. 148 The Service Provider presents two abstract services that allow 149 clients to prepare for sending and receiving messages securely: 151 * An Authentication Service (AS) which is responsible for 152 maintaining user long term identities, issuing credentials which 153 allow them to authenticate each other, and potentially allowing 154 users to discover each other's long-term identity keys. 156 * A Delivery Service (DS) which is responsible for receiving and 157 redistributing messages between group members. In the case of 158 group messaging, the delivery service may also be responsible for 159 acting as a "broadcaster" where the sender sends a single message 160 to a group which is then forwarded to each recipient in the group 161 by the DS. The DS is also responsible for storing and delivering 162 initial public key material required by clients in order to 163 proceed with the group secret key establishment process. 165 ---------------- -------------- 166 | Authentication | | Delivery | 167 | Service (AS) | | Service (DS) | 168 ---------------- -------------- 169 / | \ Group 170 / ************************************ 171 / * | \ * 172 ---------- * ---------- ---------- * 173 | Client 0 | * | Member 1 | | Member N | * 174 ---------- * ---------- ---------- * 175 ............ * ............ ............ * 176 User 0 * User 0 User 1 * 177 * * 178 ************************************ 180 In many systems, the AS and the DS are actually operated by the same 181 entity and may even be the same server. However, they are logically 182 distinct and, in other systems, may be operated by different 183 entities, hence we show them as being separate here. Other 184 partitions are also possible, such as having a separate directory 185 server. 187 A typical group messaging scenario might look like this: 189 1. Alice, Bob and Charlie create accounts with a service provider 190 and obtain credentials from the AS. 192 2. Alice, Bob and Charlie authenticate to the DS and store some 193 initial keying material which can be used to send encrypted 194 messages to them for the first time. This keying material is 195 authenticated with their long term credentials. 197 3. When Alice wants to send a message to Bob and Charlie, she 198 contacts the DS and looks up their initial keying material. She 199 uses these keys to establish a new set of keys which she can use 200 to send encrypted messages to Bob and Charlie. She then sends 201 the encrypted message(s) to the DS, which forwards them to the 202 recipients. 204 4. Bob and/or Charlie respond to Alice's message. In addtion, they 205 might choose to update their key material which provides post- 206 compromise security Section 3.2.2.1. As a consequence of that 207 change, the group secrets are updated 209 Clients may wish to do the following: 211 * create a group by inviting a set of other clients; 213 * add one or more clients to an existing group; 215 * remove one or more members from an existing group; 217 * update their own key material 219 * join an existing group; 221 * leave a group; 223 * send a message to everyone in the group; 225 * receive a message from someone in the group. 227 At the cryptographic level, clients (and by extension members in 228 groups) have equal permissions. For instance, any member can add or 229 remove another client in a group. This is in contrast to some 230 designs in which there is a single group controller who can modify 231 the group. MLS is compatible with having group administration 232 restricted to certain users, but we assume that those restrictions 233 are enforced by authentication and access control at the application 234 layer. 236 Thus, for instance, while the MLS protocol allows for any existing 237 member of a group to add a new client, applications which use MLS 238 might enforce additional restrictions for which only a subset of 239 members can qualify, and thus will handle enforcing group policies 240 (such as determining if a user is allowed to add new users to the 241 group) at the application level. 243 2.1. Group, Members and Clients 245 While informally, a group can be considered to be a set of users 246 possibly using multiple endpoint devices to interact with the Service 247 Provider, this definition is too simplistic. 249 Formally, a Client is a set of cryptographic objects composed by 250 public values such as a name (an identity), a public encryption key 251 and a public signature key. Ownership of a Client by a user is 252 determined by the fact that the user has knowledge of the associated 253 secret values. When a Client is part of a Group, it is called a 254 Member and its signature key pair uniquely defines its identity to 255 other clients or members a the Group. In some messaging systems, 256 clients belonging to the same user must all share the same identity 257 key pair, but MLS does not assume this. 259 Users will typically own multiple Clients, potentially one or more 260 per end-user devices (phones, web clients or other devices...) and 261 may choose to authenticate using the same signature key across 262 devices, using one signature key per device or even one signature key 263 per group. 265 The formal definition of a Group in MLS is the set of clients that 266 have knowledge of the shared group secret established in the group 267 key establishment phase of the protocol and have contributed to it. 268 Until a Member has contributed to the group secret, other members 269 cannot assume she is a member of the group. 271 2.2. Authentication Service 273 The basic function of the Authentication Service (AS) is to provide a 274 trusted mapping from user identities (usernames, phone numbers, 275 etc.), to long-term identity keys, which may either be one per Client 276 or may be shared amongst the clients attached to a user. 278 The Authentication Service (AS) is expected to play multiple roles in 279 the architecture: 281 * A certification authority or similar service which signs some sort 282 of portable credential binding an identity to a signature key. 284 * A directory server which provides the key for a given identity 285 (presumably this connection is secured via some form of transport 286 security such as TLS). 288 The MLS protocol assumes a signature keypair for authentication of 289 messages. It is important to note that this signature keypair might 290 be the identity keypair directly, or a different signature keypair 291 for which the public key has been for example signed by the identity 292 private key. This flexibility allows for multiple infrastructure 293 considerations and has the benefit of providing ways to use different 294 signature keys across different groups by using hierarchical 295 authentication keys. This flexibility also comes at the price of a 296 security tradeoff, described in the security considerations, between 297 potential unlinkability of the signature keys across groups and the 298 amount of time required to reinstate authentication and secrecy of 299 messages after the compromise of a device. 301 Ultimately, the only requirement is for the applications to be able 302 to check the credential containing the protocol signing key and the 303 identity against the Authentication Service at any time. 305 By definition, the Authentication Service is invested with a large 306 amount of trust. A malicious AS can impersonate - or allow an 307 attacker to impersonate - any user of the system. As a corollary, by 308 impersonating identities authorized to be members of a group, an AS 309 can break confidentiality. 311 This risk can be mitigated by publishing the binding between 312 identities and keys in a public log such as Key Transparency (KT) 313 [KeyTransparency]. It is possible to build a functional MLS system 314 without any kind of public key logging, but such a system will 315 necessarily be somewhat vulnerable to attack by a malicious or 316 untrusted AS. 318 2.3. Delivery Service 320 The Delivery Service (DS) is expected to play multiple roles in the 321 Service Provider architecture: 323 * To act as a directory service providing the initial keying 324 material for clients to use. This allows a client to establish a 325 shared key and send encrypted messages to other clients even if 326 the other client is offline. 328 * To route messages between clients and to act as a message 329 broadcaster, taking in one message and forwarding it to multiple 330 clients (also known as "server side fanout"). 332 Because the MLS protocol provides a way for Clients to send and 333 receive application messages asynchronously, it only provides causal 334 ordering of application messages from senders while it has to enforce 335 global ordering of group operations to provide Group Agreement. 337 Depending on the level of trust given by the group to the Delivery 338 Service, the functional and privacy guarantees provided by MLS may 339 differ but the Authentication and Confidentiality guarantees remain 340 the same. 342 Unlike the Authentication Service which is trusted for authentication 343 and secrecy, the Delivery Service is completely untrusted regarding 344 this property. While privacy of group membership might be a problem 345 in the case of a DS server fanout, the Delivery Service can be 346 considered as an active adaptative network attacker from the point of 347 view of the security analysis. 349 2.3.1. Key Storage 351 Upon joining the system, each client stores its initial cryptographic 352 key material with the Delivery Service. This key material, called 353 KeyPackage, advertises the functional abilities of the Client such as 354 supported protocol versions and extensions and the following 355 cryptographic information: 357 * A credential from the Authentication Service attesting to the 358 binding between the identity and the client's signature key. 360 * The client's asymmetric encryption key material signed with the 361 signature key associated with the credential. 363 As noted above, users may own multiple clients, each with their own 364 keying material, and thus there may be multiple entries stored by 365 each user. 367 The Delivery Service is also responsible for allowing users to add, 368 remove or update their initial keying material and to ensure that the 369 identifier for these keys are unique across all keys stored on the 370 DS. 372 2.3.2. Key Retrieval 374 When a client wishes to establish a group, it first contacts the DS 375 to request a KeyPackage for each other client, authenticate it using 376 the signature keys, and then can use those to form the group. 378 2.3.3. Delivery of messages and attachments 380 The main responsibility of the Delivery Service is to ensure delivery 381 of messages. Specifically, we assume that DSs provide: 383 * Reliable delivery: when a message is provided to the DS, it is 384 eventually delivered to all clients. 386 * In-order delivery: messages are delivered to the group in the 387 order they are received by the Delivery Service and in 388 approximately the order in which they are sent by clients. The 389 latter is an approximate guarantee because multiple clients may 390 send messages at the same time and so the DS needs some latitude 391 in enforcing ordering across clients. 393 * Consistent ordering: the DS must ensure that all clients have the 394 same view of message ordering for cryptographically relevant 395 operations. This means that the DS MUST enforce global 396 consistency of the ordering of group operation messages. 398 Note that the protocol provides three important information within an 399 MLSCiphertext message in order to provide ordering: 401 * The Group Identifier (GID) to allow to distinguish the group for 402 which the message has been sent; 404 * The Epoch number, which represent the number of changes (version) 405 of the group associated with a specific GID, and allows for 406 lexicographical ordering of two messages from the same group; 408 * The Content Type of the message, which allows the DS to determine 409 the ordering requirement on the message. 411 The MLS protocol itself can verify these properties. For instance, 412 if the DS reorders messages from a Client or provides different 413 Clients with inconsistent orderings, then Clients can detect this 414 misconduct. However, the protocol relies on the ordering, and on the 415 fact that only one honest group operation message is faned-out to 416 clients per Epoch, to provide Clients with a consistent view of the 417 evolving Group State. 419 Note that some forms of DS misbehavior are still possible and 420 difficult to detect. For instance, a DS can simply refuse to relay 421 messages to and from a given client. Without some sort of side 422 information, other clients cannot generally distinguish this form of 423 Denial of Service (DoS) attack. 425 2.3.4. Membership knowledge 427 Group membership is itself sensitive information and MLS is designed 428 to drastically limit the amount of persisted metadata. However, 429 large groups often require an infrastructure which provides server 430 fanout. In the case of client fanout, the destinations of a message 431 is known by all clients, hence the server usually does not need this 432 information. However, they may learn this information through 433 traffic analysis. Unfortunately, in a server side fanout model, the 434 DS can learn that a given client is sending the same message to a set 435 of other clients. In addition, there may be applications of MLS in 436 which the group membership list is stored on some server associated 437 with the DS. 439 While this knowledge is not a break of authentication or 440 confidentiality, it is a serious issue for privacy. In the case 441 where metadata has to be persisted for functionality, it SHOULD be 442 stored encrypted at rest. 444 2.3.5. Membership and offline members 446 Because Forward Secrecy (FS) and Post-Compromise Security (PCS) rely 447 on the active deletion and replacement of keying material, any client 448 which is persistently offline may still be holding old keying 449 material and thus be a threat to both FS and PCS if it is later 450 compromised. 452 MLS cannot inherently defend against this problem, especially in the 453 case where the Client hasn't processed messages but MLS-using systems 454 can enforce some mechanism to try retaining these properties. 455 Typically this will consist of evicting clients which are idle for 456 too long, thus containing the threat of compromise. The precise 457 details of such mechanisms are a matter of local policy and beyond 458 the scope of this document. 460 3. System Requirements 462 3.1. Functional Requirements 464 MLS is designed as a large scale group messaging protocol and hence 465 aims to provide performance and safety to its users. Messaging 466 systems that implement MLS provide support for conversations 467 involving two or more members, and aim to scale to groups as large as 468 50,000 members, typically including many users using multiple 469 devices. 471 3.1.1. Asynchronous Usage 473 No operation in MLS requires two distinct clients or members to be 474 online simultaneously. In particular, members participating in 475 conversations protected using MLS can update shared keys, add or 476 remove new members, and send messages and attachments without waiting 477 for another user's reply. 479 Messaging systems that implement MLS have to provide a transport 480 layer for delivering messages asynchronously and reliably. 482 3.1.2. Recovery After State Loss 484 Conversation participants whose local MLS state is lost or corrupted 485 can reinitialize their state and continue participating in the 486 conversation. 488 [[OPEN ISSUE: The previous statement seems too strong, establish what 489 exact functional requirement we have regarding state recovery. 490 Previously: "This may entail some level of message loss, but does not 491 result in permanent exclusion from the group."]] 493 3.1.3. Support for Multiple Devices 495 It is typically expected for users within a Group to own different 496 devices. 498 A new device can be added to a group and be considered as a new 499 client by the protocol. This client will not gain access to the 500 history even if it is owned by someone who owns another member of the 501 Group. Restoring history is typically not allowed at the protocol 502 level but applications can elect to provide such a mechanism outside 503 of MLS. Such mechanisms, if used, may undermine the FS and PCS 504 guarantees provided by MLS. 506 3.1.4. Extensibility / Pluggability 508 Messages that do not affect the group state can carry an arbitrary 509 payload with the purpose of sharing that payload between group 510 members. No assumptions are made about the format of the payload. 512 3.1.5. Privacy 514 The protocol is designed in a way that limits the server-side (AS and 515 DS) metadata footprint. The DS only persists data required for the 516 delivery of messages and avoids Personally Identifiable Information 517 (PII) or other sensitive metadata wherever possible. A Service 518 Provider that has control over both the AS and the DS, will not be 519 able to correlate encrypted messages forwarded by the DS, with the 520 initial public keys signed by the AS. 522 [[OPEN ISSUE: These privacy statements seem very strong. BB. I 523 would be willing to keep them as requirements since we have example 524 solutions in the Server-Assist draft.]] 526 3.1.6. Federation 528 The protocol aims to be compatible with federated environments. 529 While this document does not specify all necessary mechanisms 530 required for federation, multiple MLS implementations can 531 interoperate to form federated systems if they use compatible 532 authentication mechanisms and infrastructure functionalities. 534 3.1.7. Compatibility with future versions of MLS 536 It is important that multiple versions of MLS be able to coexist in 537 the future. Thus, MLS offers a version negotiation mechanism; this 538 mechanism prevents version downgrade attacks where an attacker would 539 actively rewrite messages with a lower protocol version than the ones 540 originally offered by the endpoints. When multiple versions of MLS 541 are available, the negotiation protocol guarantees that the version 542 agreed upon will be the highest version supported in common by the 543 group. 545 In MLS 1.0, the creator of the group is responsible for selecting the 546 best ciphersuite proposed across clients. Each client is able to 547 verify availability of protocol version, ciphersuites and extensions 548 at all times once he has at least received the first group operation 549 message. 551 3.2. Security Requirements 552 3.2.1. Connections between Clients and Servers (one-to-one) 554 We assume that all transport connections are secured via some 555 transport layer security mechanism such as TLS [RFC8446]. However, 556 as noted above, the security of MLS will generally survive compromise 557 of the transport layer, so long as identity keys provided by the AS 558 are authenticated at a minimum. However, MLS ciphertext contains the 559 Group Identifier, Epoch number and Content Type that may be used to 560 improve attacks on the privacy of the group. 562 3.2.2. Message Secrecy and Authentication 564 The trust establishment step of the MLS protocol is followed by a 565 conversation protection step where encryption is used by clients to 566 transmit authenticated messages to other clients through the DS. 567 This ensures that the DS does not have access to the group's private 568 content. 570 MLS aims to provide secrecy, integrity and authentication for all 571 messages. 573 Message Secrecy in the context of MLS means that only intended 574 recipients (current group members), can read any message sent to the 575 group, even in the context of an active attacker as described in the 576 threat model. 578 Message Integrity and Authentication mean that an honest Client can 579 only accept a message if it was sent by a group member and that no 580 Client can send a message which other Clients accept as being from 581 another Client. 583 A corollary to this statement is that the AS and the DS cannot read 584 the content of messages sent between Members as they are not Members 585 of the Group. MLS optionally provides additional protections 586 regarding traffic analysis so as to reduce the ability of attackers, 587 or a compromised member of the messaging system, to deduce the 588 content of the messages depending on (for example) their size. One 589 of these protections includes padding messages in order to produce 590 ciphertexts of standard length. While this protection is highly 591 recommended it is not mandatory as it can be costly in terms of 592 performance for clients and the SP. 594 Message content can be deniable if the signature keys are exchanged 595 over a deniable channel prior to signing messages. 597 3.2.2.1. Forward and Post-Compromise Security 599 MLS provides additional protection regarding secrecy of past messages 600 and future messages. These cryptographic security properties are 601 Forward Secrecy (FS) and Post-Compromise Security (PCS). 603 FS means that access to all encrypted traffic history combined with 604 an access to all current keying material on clients will not defeat 605 the secrecy properties of messages older than the oldest key of the 606 compromised client. Note that this means that clients have the 607 extremely important role of deleting appropriate keys as soon as they 608 have been used with the expected message, otherwise the secrecy of 609 the messages and the security for MLS is considerably weakened. 611 PCS means that if a group member's state is compromised at some time 612 t but the group member subsequently performs an update at some time 613 t', then all MLS guarantees apply to messages sent by the member 614 after time t', and by other members after they have processed the 615 update. For example, if an attacker learns all secrets known to 616 Alice at time t, including both Alice's long-term secret keys and all 617 shared group keys, but Alice performs a key update at time t', then 618 the attacker is unable to violate any of the MLS security properties 619 after the updates have been processed. 621 Both of these properties are satisfied even against compromised DSs 622 and ASs. 624 3.2.2.2. Membership Changes 626 MLS aims to provide agreement on group membership, meaning that all 627 group members have agreed on the list of current group members. 629 Some applications may wish to enforce ACLs to limit addition or 630 removal of group members, to privileged clients or users. Others may 631 wish to require authorization from the current group members or a 632 subset thereof. Regardless, MLS does not allow addition or removal 633 of group members without informing all other members. 635 Once a client is part of a group, the set of devices controlled by 636 the user can only be altered by an authorized member of the group. 637 This authorization could depend on the application: some applications 638 might want to allow certain other members of the group to add or 639 remove devices on behalf of another member, while other applications 640 might want a more strict policy and allow only the owner of the 641 devices to add or remove them at the potential cost of weaker PCS 642 guarantees. 644 Members who are removed from a group do not enjoy special privileges: 645 compromise of a removed group member does not affect the security of 646 messages sent after their removal but might affect previous messages 647 if the group secrets have not been deleted properly. 649 3.2.2.3. Parallel Groups 651 Any user may have membership in several Groups simultaneously. The 652 set of members of any group may or may not form a subset of the 653 members of another group. MLS guarantees that the FS and PCS goals 654 are maintained and not weakened by user membership in multiple 655 groups. 657 3.2.2.4. Security of Attachments 659 The security properties expected for attachments in the MLS protocol 660 are very similar to the ones expected from messages. The distinction 661 between messages and attachments stems from the fact that the typical 662 average time between the download of a message and the one from the 663 attachments may be different. For many reasons (a typical reason 664 being the lack of high bandwidth network connectivity), the lifetime 665 of the cryptographic keys for attachments is usually higher than for 666 messages, hence slightly weakening the PCS guarantees for 667 attachments. 669 3.2.2.5. Denial of Service 671 In general we do not consider Denial of Service (DoS) resistance to 672 be the responsibility of the protocol. However, it should not be 673 possible for anyone aside from the DS to perform a trivial DoS attack 674 from which it is hard to recover. 676 3.2.2.6. Non-Repudiation vs Deniability 678 As described in Section 4.4, MLS provides strong authentication 679 within a group, such that a group member cannot send a message that 680 appears to be from another group member. Additionally, some services 681 require that a recipient be able to prove to the service provider 682 that a message was sent by a given client, in order to report abuse. 683 MLS supports both of these use cases. In some deployments, these 684 services are provided by mechanisms which allow the receiver to prove 685 a message's origin to a third party (this if often called "non- 686 repudiation"), but it should also be possible to operate MLS in a 687 "deniable" mode where such proof is not possible. [[OPEN ISSUE: 688 Exactly how to supply this is still a protocol question.]] 690 4. Security Considerations 692 MLS adopts the Internet threat model [RFC3552] and therefore assumes 693 that the attacker has complete control of the network. It is 694 intended to provide the security services described in the face of 695 such attackers. In addition, these guarantees are intended to 696 degrade gracefully in the presence of compromise of the transport 697 security links as well as of both Clients and elements of the 698 messaging system, as described in the remainder of this section. 700 4.1. Transport Security Links 702 [TODO: Mostly DoS, message suppression, and leakage of group 703 membership.] 705 4.2. Delivery Service Compromise 707 MLS is intended to provide strong guarantees in the face of 708 compromise of the DS. Even a totally compromised DS should not be 709 able to read messages or inject messages that will be acceptable to 710 legitimate clients. It should also not be able to undetectably 711 remove, reorder or replay messages. 713 However, a DS can mount a variety of DoS attacks on the system, 714 including total DoS attacks (where it simply refuses to forward any 715 messages) and partial DoS attacks (where it refuses to forward 716 messages to and from specific clients). As noted in Section 2.3.3, 717 these attacks are only partially detectable by clients without an 718 out-of-band channel. Ultimately, failure of the DS to provide 719 reasonable service must be dealt with as a customer service matter, 720 not via technology. 722 Because the DS is responsible for providing the initial keying 723 material to clients, it can provide stale keys. This does not 724 inherently lead to compromise of the message stream, but does allow 725 it to attack forward security to a limited extent. This threat can 726 be mitigated by having initial keys expire. 728 4.3. Authentication Service Compromise 730 A compromised AS is a serious matter, as the AS can provide incorrect 731 or attacker-provided identities to clients. As noted in Section 2.2, 732 detecting this form of attack requires some sort of transparency/ 733 logging mechanism. Without such a mechanism, MLS cannot detect a 734 compromised AS. 736 4.4. Client Compromise 738 MLS provides a limited form of protection against compromised Clients 739 through PCS. When the Client is fully compromised, then the attacker 740 will be able to decrypt any messages for groups in which the Client 741 is a member, and will be able to send messages impersonating the 742 compromised Client. However, if the Client afterwards updates its 743 keying material (see Section 3.2.2.1) (using fresh randomness that 744 the attacker does not know) then the PCS property enables the Client 745 to recover. 747 In addition, a client cannot send a message to a group which appears 748 to be from another client with a different identity. Note that if 749 devices from the same user share keying material, then one will be 750 able to impersonate another. 752 Finally, clients should not be able to perform DoS attacks 753 Section 3.2.2.5. 755 5. IANA Considerations 757 This document makes no requests of IANA. 759 6. Contributors 761 * Katriel Cohn-Gordon 763 University of Oxford 765 me@katriel.co.uk 767 * Cas Cremers 769 University of Oxford 771 cas.cremers@cs.ox.ac.uk 773 * Thyla van der Merwe 775 Royal Holloway, University of London 777 thyla.van.der@merwe.tech 779 * Jon Millican 781 Facebook 783 jmillican@fb.com 785 * Raphael Robert 787 Wire 789 raphael@wire.com 791 7. Informative References 793 [KeyTransparency] 794 Google, ., "Key Transparency", 2017, 795 . 797 [MLSPROTO] Barnes, R., Beurdouche, B., Millican, J., Omara, E., Cohn- 798 Gordon, K., and R. Robert, "Messaging Layer Security 799 Protocol", 2018. 801 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 802 Text on Security Considerations", BCP 72, RFC 3552, 803 DOI 10.17487/RFC3552, July 2003, 804 . 806 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 807 Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, 808 March 2011, . 810 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 811 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 812 October 2013, . 814 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 815 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 816 2014, . 818 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 819 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 820 . 822 Authors' Addresses 824 Emad Omara 825 Google 827 Email: emadomara@google.com 829 Benjamin Beurdouche 830 INRIA 831 Email: benjamin.beurdouche@inria.fr 833 Eric Rescorla 834 Mozilla 836 Email: ekr@rtfm.com 838 Srinivas Inguva 839 Twitter 841 Email: singuva@twitter.com 843 Albert Kwon 844 MIT 846 Email: kwonal@mit.edu 848 Alan Duric 849 Wire 851 Email: alan@wire.com