idnits 2.17.1 draft-ietf-mls-architecture-01.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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 22, 2018) is 2012 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: April 25, 2019 INRIA 6 E. Rescorla 7 Mozilla 8 S. Inguva 9 Twitter 10 A. Kwon 11 MIT 12 A. Duric 13 Wire 14 October 22, 2018 16 The Messaging Layer Security (MLS) Architecture 17 draft-ietf-mls-architecture-01 19 Abstract 21 This document describes the architecture and requirements for the 22 Messaging Layer Security (MLS) protocol. MLS provides a security 23 layer for group messaging applications with from two to a large 24 number of clients. It is meant to protect against eavesdropping, 25 tampering, and message forgery. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on April 25, 2019. 44 Copyright Notice 46 Copyright (c) 2018 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. General Setting . . . . . . . . . . . . . . . . . . . . . . . 3 63 2.1. Group, Members and Clients . . . . . . . . . . . . . . . 5 64 2.2. Authentication Service . . . . . . . . . . . . . . . . . 6 65 2.3. Delivery Service . . . . . . . . . . . . . . . . . . . . 6 66 2.3.1. Key Storage . . . . . . . . . . . . . . . . . . . . . 7 67 2.3.2. Key Retrieval . . . . . . . . . . . . . . . . . . . . 7 68 2.3.3. Delivery of messages and attachments . . . . . . . . 7 69 2.3.4. Membership knowledge . . . . . . . . . . . . . . . . 8 70 2.3.5. Membership and offline members . . . . . . . . . . . 8 71 3. System Requirements . . . . . . . . . . . . . . . . . . . . . 9 72 3.1. Functional Requirements . . . . . . . . . . . . . . . . . 9 73 3.1.1. Asynchronous Usage . . . . . . . . . . . . . . . . . 9 74 3.1.2. Recovery After State Loss . . . . . . . . . . . . . . 9 75 3.1.3. Support for Multiple Devices . . . . . . . . . . . . 9 76 3.1.4. Extensibility / Pluggability . . . . . . . . . . . . 9 77 3.1.5. Privacy . . . . . . . . . . . . . . . . . . . . . . . 10 78 3.1.6. Federation . . . . . . . . . . . . . . . . . . . . . 10 79 3.1.7. Compatibility with future versions of MLS . . . . . . 10 80 3.2. Security Requirements . . . . . . . . . . . . . . . . . . 10 81 3.2.1. Connections between Clients and Servers (one-to-one) 10 82 3.2.2. Message Secrecy and Authentication . . . . . . . . . 10 83 4. Security Considerations . . . . . . . . . . . . . . . . . . . 13 84 4.1. Transport Security Links . . . . . . . . . . . . . . . . 13 85 4.2. Delivery Service Compromise . . . . . . . . . . . . . . . 13 86 4.3. Authentication Service Compromise . . . . . . . . . . . . 14 87 4.4. Client Compromise . . . . . . . . . . . . . . . . . . . . 14 88 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 89 6. Informative References . . . . . . . . . . . . . . . . . . . 15 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 92 1. Introduction 94 RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH 95 The source for this draft is maintained in GitHub. Suggested changes 96 should be submitted as pull requests at https://github.com/mlswg/mls- 97 architecture. Instructions are on that page as well. Editorial 98 changes can be managed in GitHub, but any substantive change should 99 be discussed on the MLS mailing list. 101 End-to-end security is a requirement for instant messaging systems 102 and is commonly deployed in many such systems. In this context, 103 "end-to-end" captures the notion that users of the system enjoy some 104 level of security - with the precise level depending on the system 105 design - even when the messaging service they are using performs 106 unsatisfactorily. 108 Messaging Layer Security (MLS) specifies an architecture (this 109 document) and an abstract protocol [MLSPROTO] for providing end-to- 110 end security in this setting. MLS is not intended as a full instant 111 messaging protocol but rather is intended to be embedded in a 112 concrete protocol such as XMPP [RFC6120]. In addition, it does not 113 specify a complete wire encoding, but rather a set of abstract data 114 structures which can then be mapped onto a variety of concrete 115 encodings, such as TLS [I-D.ietf-tls-tls13], CBOR [RFC7049], and JSON 116 [RFC7159]. Implementations which adopt compatible encodings will 117 have some degree of interoperability at the message level, though 118 they may have incompatible identity/authentication infrastructures. 120 This document is intended to describe the overall messaging system 121 architecture which the MLS protocol fits into, and the requirements 122 which it is intended to fulfill. 124 2. General Setting 126 A Group using a Messaging Service (MS) comprises a set of 127 participants called Members where each Member is typically expected 128 to own multiple devices, called Clients. A group may be as small as 129 two members (the simple case of person to person messaging) or as 130 large as thousands. In order to communicate securely, Group Members 131 initially use services at their disposal to obtain the necessary 132 secrets and credentials required for security. 134 The Messaging Service (MS) presents as two abstract services that 135 allow Members to prepare for sending and receiving messages securely: 137 o An Authentication Service (AS) which is responsible for 138 maintaining user long term identities, issuing credentials which 139 allow them to authenticate each other, and potentially allowing 140 users to discover each others long-term identity keys. 142 o A Delivery Service (DS) which is responsible for receiving and 143 redistributing messages between group members. In the case of 144 group messaging, the delivery service may also be responsible for 145 acting as a "broadcaster" where the sender sends a single message 146 to a group which is then forwarded to each recipient in the group 147 by the DS. The DS is also responsible for storing and delivering 148 initial public key material required in order to proceed with the 149 group secret key establishment process. 151 ---------------- -------------- 152 | Authentication | | Delivery | 153 | Service (AS) | | Service (DS) | 154 ---------------- -------------- 155 / | \ Group 156 ********************************************************* 157 * / | \ * 158 * / | \ * 159 * ---------- ---------- ---------- * 160 * | Client 0 | | Client 1 | | Client N | * 161 * ---------- ---------- ---------- * 162 * ............................ ........... * 163 * Member 0 Member 1 * 164 * * 165 ********************************************************* 167 In many systems, the AS and the DS are actually operated by the same 168 entity and may even be the same server. However, they are logically 169 distinct and, in other systems, may be operated by different 170 entities, hence we show them as being separate here. Other 171 partitions are also possible, such as having a separate directory 172 server. 174 A typical group messaging scenario might look like this: 176 1. Alice, Bob and Charlie create accounts with a messaging service 177 and obtain credentials from the AS. 179 2. Alice, Bob and Charlie authenticate to the DS and store some 180 initial keying material which can be used to send encrypted 181 messages to them for the first time. This keying material is 182 authenticated with their long term credentials. 184 3. When Alice wants to send a message to Bob and Charlie, she 185 contacts the DS and looks up their initial keying material. She 186 uses these keys to establish a new set of keys which she can use 187 to send encrypted messages to Bob and Charlie. She then sends 188 the encrypted message(s) to the DS, which forwards them to the 189 recipients. 191 4. Bob and/or Charlie respond to Alice's message. Their messages 192 might trigger a new key derivation step which allows the shared 193 group key to be updated to provide post-compromise security 194 Section 3.2.2.1. 196 Clients may wish to do the following: 198 o create a group by inviting a set of other members; 200 o add one or more members to an existing group; 202 o remove one or more members from an existing group; 204 o join an existing group; 206 o leave a group; 208 o send a message to everyone in the group; 210 o receive a message from someone in the group. 212 At the cryptographic level, Clients in groups (and by extension 213 Members) are peers. For instance, any Client can add a member to a 214 group. This is in contrast to some designs in which there is a 215 single group controller who can modify the group. MLS is compatible 216 with having group administration restricted to certain users, but we 217 assume that those restrictions are enforced by authentication and 218 access control. Thus, for instance, while it might be technically 219 possible for any member to send a message adding a new member to a 220 group, the group might have the policy that only certain members are 221 allowed to make changes and thus other members can ignore or reject 222 such a message from an unauthorized user. 224 2.1. Group, Members and Clients 226 In MLS a Group is defined as a set of Members who possibly use 227 multiple endpoint devices (Clients) to interact with the Messaging 228 Service. These Clients will typically correspond to end-user devices 229 such as phones, web clients or other devices running MLS. 231 Each member device owns a long term identity key pair that uniquely 232 defines its identity to other Members of the Group. Because a single 233 Member may operate multiple devices simultaneously (e.g., a desktop 234 and a phone) or sequentially (e.g., replacing one phone with 235 another), the formal definition of a Group in MLS is the set of 236 Clients that has legitimate knowledge of the shared (Encryption) 237 Group Key established in the group key establishment phase of the 238 protocol. 240 In some messaging systems, Clients belonging to the same Member must 241 all share the same identity key pair, but MLS does not assume this. 242 The MLS architecture considers the more general case and allows for 243 important use cases, such as a Member adding a new Client when all 244 their existing clients are offline. 246 MLS has been designed to provide similar security guarantees to all 247 Clients, for all group sizes, even when it reduces to only two 248 Clients. 250 2.2. Authentication Service 252 The basic function of the Authentication Service is to provide a 253 trusted mapping from user identities (usernames, phone numbers, 254 etc.), which exist 1:1 with Members, to identity keys, which may 255 either be one per Client or may be shared amongst the Clients 256 attached to a Member. 258 o A certification authority or similar service which signs some sort 259 of portable credential binding an identity to a key. 261 o A directory server which provides the key for a given identity 262 (presumably this connection is secured via some form of transport 263 security such as TLS). 265 By definition, the AS is invested with a large amount of trust. A 266 malicious AS can impersonate - or allow an attacker to impersonate - 267 any user of the system. This risk can be mitigated by publishing the 268 binding between identities and keys in a public log such as Key 269 Transparency (KT) [KeyTransparency]. It is possible to build a 270 functional MLS system without any kind of public key logging, but 271 such a system will necessarily be somewhat vulnerable to attack by a 272 malicious or untrusted AS. 274 2.3. Delivery Service 276 The Delivery Service (DS) is expected to play multiple roles in the 277 Messaging Service architecture: 279 o To act as a directory service providing the keying material 280 (authentication keys and initial keying material) for Clients to 281 use. This allows a Client to establish a shared key and send 282 encrypted messages to other Clients even if the other Client is 283 offline. 285 o To route messages between Clients and to act as a message 286 broadcaster, taking in one message and forwarding it to multiple 287 Clients (also known as "server side fanout"). 289 Depending on the level of trust given by the Group to the Delivery 290 Service, the functional and security guarantees provided by MLS may 291 differ. 293 2.3.1. Key Storage 295 Upon joining the system, each Client stores its initial cryptographic 296 key material with the DS. This key material represents the initial 297 contribution from each member that will be used in the establishment 298 of the shared group key. This initial keying material is 299 authenticated using the Client's identity key. Thus, the Client 300 stores: 302 o A credential from the Authentication service attesting to the 303 binding between the Member and the Client's identity key. 305 o The member's initial keying material signed with the Client's 306 identity key. 308 As noted above, Members may have multiple Clients, each with their 309 own keying material, and thus there may be multiple entries stored by 310 each Member. 312 2.3.2. Key Retrieval 314 When a Client wishes to establish a group and send an initial message 315 to that group, it contacts the DS and retrieves the initial key 316 material for each other Member, verifies it using the identity key, 317 and then is able to form a joint key with each other Client, and from 318 those forms the group key, which it can use for the encryption of 319 messages. 321 2.3.3. Delivery of messages and attachments 323 The DS's main responsibility is to ensure delivery of messages. 324 Specifically, we assume that DSs provide: 326 o Reliable delivery: when a message is provided to the DS, it is 327 eventually delivered to all group members. 329 o In-order delivery: messages are delivered to the group in the 330 order they are received from a given Client and in approximately 331 the order in which they are sent by Clients. The latter is an 332 approximate guarantee because multiple Clients may send messages 333 at the same time and so the DS needs some latitude in reordering 334 between Clients. 336 o Consistent ordering: the DS must ensure that all Clients have the 337 same view of message ordering. 339 Note that the DS may provide ordering guarantees by ensuring in-order 340 delivery or by providing messages with some kind of sequence 341 information and allowing clients to reorder on receipt. 343 The MLS protocol itself can verify these properties. For instance, 344 if the DS reorders messages from a Client or provides different 345 Clients with inconsistent orderings, then Clients can to detect this 346 misconduct. However, MLS need not provide mechanisms to recover from 347 a misbehaving DS. 349 Note that some forms of DS misbehavior are still possible and 350 difficult to detect. For instance, a DS can simply refuse to relay 351 messages to and from a given Client. Without some sort of side 352 information, other Clients cannot generally distinguish this form of 353 Denial of Service (DoS) attack from the Client being actually 354 offline. 356 2.3.4. Membership knowledge 358 Group membership is itself sensitive information and MLS is designed 359 so that neither the DS nor the AS need have static knowledge of which 360 Clients are in which Group. However, they may learn this information 361 through traffic analysis. For instance, in a server side fanout 362 model, the DS learns that a given Client is sending the same message 363 to a set of other Clients. In addition, there may be applications of 364 MLS in which the Group membership list is stored on some server 365 associated with the MS. 367 2.3.5. Membership and offline members 369 Because Forward Secrecy (FS) and Post-Compromise Security (PCS) rely 370 on the deletion and replacement of keying material, any Client which 371 is persistently offline may still be holding old keying material and 372 thus be a threat to both FS and PCS if it is later compromised. MLS 373 does not inherently defend against this problem, but MLS-using 374 systems can enforce some mechanism for doing so. Typically this will 375 consist of evicting Clients which are idle for too long, thus 376 containing the threat of compromise. The precise details of such 377 mechanisms are a matter of local policy and beyond the scope of this 378 document. 380 3. System Requirements 382 3.1. Functional Requirements 384 MLS is designed as a large scale group messaging protocol and hence 385 aims to provide performance and safety to its users. Messaging 386 systems that implement MLS provide support for conversations 387 involving two or more participants, and aim to scale to approximately 388 50,000 clients, typically including many Members using multiple 389 devices. 391 3.1.1. Asynchronous Usage 393 No operation in MLS requires two distinct users to be online 394 simultaneously. In particular, clients participating in 395 conversations protected using MLS can update shared keys, add or 396 remove new members, and send messages and attachments without waiting 397 for another user's reply. 399 Messaging systems that implement MLS provide a transport layer for 400 delivering messages asynchronously and reliably. 402 3.1.2. Recovery After State Loss 404 Conversation participants whose local MLS state is lost or corrupted 405 can reinitialize their state and continue participating in the 406 conversation. This may entail some level of message loss, but does 407 not result in permanent exclusion from the group. 409 3.1.3. Support for Multiple Devices 411 It is typically expected for Members of the Group to own different 412 devices. 414 A new device can join the group and will be considered as a new 415 Client by the protocol. This Client will not gain access to the 416 history even if it is owned by someone who is already a Member of the 417 Group. Restoring history is typically not allowed at the protocol 418 level but applications can elect to provide such a mechanism outside 419 of MLS. 421 3.1.4. Extensibility / Pluggability 423 Messages that do not affect the group state can carry an arbitrary 424 payload with the purpose of sharing that payload between group 425 members. No assumptions are made about the format of the payload. 427 3.1.5. Privacy 429 The protocol is designed in a way that limits the server-side (AS and 430 DS) metadata footprint. The DS only persists data required for the 431 delivery of messages and avoid Personally Identifiable Information 432 (PII) or other sensitive metadata wherever possible. A Messaging 433 Service provider that has control over both the AS and the DS, will 434 not be able to correlate encrypted messages forwarded by the DS, with 435 the initial public keys signed by the AS. 437 3.1.6. Federation 439 The protocol aims to be compatible with federated environments. 440 While this document does not specify all necessary mechanisms 441 required for federation, multiple MLS implementations can 442 interoperate and to form federated systems if they use compatible 443 wire encodings. 445 3.1.7. Compatibility with future versions of MLS 447 It is important that multiple versions of MLS be able to coexist in 448 the future. Thus, MLS offers a version negotiation mechanism; this 449 mechanism prevents version downgrade attacks where an attacker would 450 actively rewrite messages messages with a lower protocol version than 451 the ones originally offered by the endpoints. When multiple versions 452 of MLS are available, the negotiation protocol guarantees that the 453 version agreed upon will be the highest version supported in common 454 by the group. 456 3.2. Security Requirements 458 3.2.1. Connections between Clients and Servers (one-to-one) 460 We assume that all transport connections are secured via some 461 transport layer security mechanism such as TLS [I-D.ietf-tls-tls13]. 462 However, as noted above, the security of MLS will generally survive 463 compromise of the transport layer, so long as identities provided by 464 the AS are authenticated at a minimum. 466 3.2.2. Message Secrecy and Authentication 468 The trust establishment step of the MLS protocol is followed by a 469 conversation protection step where encryption is used by clients to 470 transmit authenticated messages to other clients through the DS. 471 This ensures that the DS does not have access to the Group's private 472 content. 474 MLS aims to provide Secrecy, Integrity and Authentication for all 475 messages. 477 Message Secrecy in the context of MLS means that only intended 478 recipients (current group members), can read any message sent to the 479 group, even in the context of an active adversary as described in the 480 threat model. 482 Message Integrity and Authentication mean that an honest Client can 483 only accept a message if it was sent by a group member and that one 484 Client cannot send a message which other Clients accept as being from 485 another Client. 487 A corollary to this statement is that the AS and the DS cannot read 488 the content of messages sent between Members as they are not Members 489 of the Group. MLS optionally provides additional protections 490 regarding traffic analysis so as to reduce the ability of 491 adversaries, or a compromised member of the messaging system, to 492 deduce the content of the messages depending on (for example) their 493 size. One of these protections includes padding messages in order to 494 produce ciphertexts of standard length. While this protection is 495 highly recommended it is not mandatory as it can be costly in terms 496 of performance for clients and the MS. 498 Message content can be deniable if the signature keys are exchanged 499 over a deniable channel prior to signing messages. 501 3.2.2.1. Forward and Post-Compromise Security 503 MLS provides additional protection regarding secrecy of past messages 504 and future messages. These cryptographic security properties are 505 Forward Secrecy (FS) and Post-Compromise Security (PCS). 507 FS means that access to all encrypted traffic history combined with 508 an access to all current keying material on clients will not defeat 509 the secrecy properties of messages older than the oldest key of the 510 client. Note that this means that clients have the extremely 511 important role of deleting appropriate keys as soon as they have been 512 used with the expected message, otherwise the secrecy of the messages 513 and the security for MLS is considerably weakened. 515 PCS means that if a group member is compromised at some time t but 516 subsequently performs an update at some time t', then all MLS 517 guarantees apply to messages sent after time t'. For example, if an 518 adversary learns all secrets known to Alice at time t, including both 519 Alice's secret keys and all shared group keys, but Alice performs a 520 key update at time t', then the adversary is unable to violate any of 521 the MLS security properties after time t'. 523 Both of these properties are satisfied even against compromised DSs 524 and ASs. 526 3.2.2.2. Membership Changes 528 MLS aims to provide agreement on group membership, meaning that all 529 group members have agreed on the list of current group members. 531 Some applications may wish to enforce ACLs to limit addition or 532 removal of group members, to privileged users. Others may wish to 533 require authorization from the current group members or a subset 534 thereof. Regardless, MLS does not allow addition or removal of group 535 members without informing all other members. 537 Once a Member is part of a Group, the set of devices controlled by 538 the member can only be altered by an authorized member of the group. 539 This authorization could depend on the application: some applications 540 might want to allow certain other members of the group to add or 541 remove devices on behalf of another member, while other applications 542 might want a more strict policy and allow only the owner of the 543 devices to add or remove them at the potential cost of weaker PCS 544 guarantees. 546 Members who are removed from a group do not enjoy special privileges: 547 compromise of a removed group member does not affect the security of 548 messages sent after their removal. 550 3.2.2.3. Security of Attachments 552 The security properties expected for attachments in the MLS protocol 553 are very similar to the ones expected from messages. The distinction 554 between messages and attachments stems from the fact that the typical 555 average time between the download of a message and the one from the 556 attachments may be different. For many reasons (a typical reason 557 being the lack of high bandwidth network connectivity), the lifetime 558 of the cryptographic keys for attachments is usually higher than for 559 messages, hence slightly weakening the PCS guarantees for 560 attachments. 562 3.2.2.4. Denial of Service 564 In general we do not consider Denial of Service (DoS) resistance to 565 be the responsibility of the protocol. However, it should not be 566 possible for anyone aside from the DS to perform a trivial DoS attack 567 from which it is hard to recover. 569 3.2.2.5. Non-Repudiation and Deniability 571 As described in Section 4.4, MLS provides data origin authentication 572 within a group, such that one group member cannot send a message that 573 appears to be from another group member. Additionally, some services 574 require that a recipient be able to prove to the messaging service 575 that a message was sent by a given Client, in order to report abuse. 576 MLS supports both of these use cases. In some deployments, these 577 services are provided by mechanisms which allow the receiver to prove 578 a message's origin to a third party (this if often called "non- 579 repudiation"), but it should also be possible to operate MLS in a 580 "deniable" mode where such proof is not possible. [[OPEN ISSUE: 581 Exactly how to supply this is still a protocol question.]] 583 4. Security Considerations 585 MLS adopts the Internet threat model [RFC3552] and therefore assumes 586 that the attacker has complete control of the network. It is 587 intended to provide the security services described in in the face of 588 such attackers. In addition, these guarantees are intended to 589 degrade gracefully in the presence of compromise of the transport 590 security links as well as of both Clients and elements of the 591 messaging system, as described in the remainder of this section. 593 4.1. Transport Security Links 595 [TODO: Mostly DoS, message suppression, and leakage of group 596 membership.] 598 4.2. Delivery Service Compromise 600 MLS is intended to provide strong guarantees in the face of 601 compromise of the DS. Even a totally compromised DS should not be 602 able to read messages or inject messages that will be acceptable to 603 legitimate Clients. It should also not be able to undetectably 604 remove, reorder or replay messages. 606 However, a DS can mount a variety of DoS attacks on the system, 607 including total DoS attacks (where it simply refuses to forward any 608 messages) and partial DoS attacks (where it refuses to forward 609 messages to and from specific Clients). As noted in Section 2.3.3, 610 these attacks are only partially detectable by clients without an 611 out-of-band channel. Ultimately, failure of the DS to provide 612 reasonable service must be dealt with as a customer service matter, 613 not via technology. 615 Because the DS is responsible for providing the initial keying 616 material to Clients, it can provide stale keys. This does not 617 inherently lead to compromise of the message stream, but does allow 618 it to attack forward security to a limited extent. This threat can 619 be mitigated by having initial keys expire. 621 4.3. Authentication Service Compromise 623 A compromised AS is a serious matter, as the AS can provide incorrect 624 or adversarial identities to clients. As noted in Section 2.2, 625 mitigating this form of attack requires some sort of transparency/ 626 logging mechanism. Without such a mechanism, MLS will only provide 627 limited security against a compromised AS. 629 4.4. Client Compromise 631 In general, MLS only provides limited protection against compromised 632 Clients. When the Client is compromised, then the attacker will 633 obviously be able to decrypt any messages for groups in which the 634 Client is a member. It will also be able to send messages 635 impersonating the compromised Client until the Client updates its 636 keying material (see Section 3.2.2.1). MLS attempts to provide some 637 security in the face of client compromise. 639 In addition, a Client cannot send a message to a group which appears 640 to be from another Client with a different identity. Note that if 641 Clients from the same Member share keying material, then one will be 642 able to impersonate another. 644 Finally, Clients should not be able to perform DoS attacks 645 Section 3.2.2.4. 647 5. Contributors 649 o Katriel Cohn-Gordon 650 University of Oxford 651 me@katriel.co.uk 653 o Cas Cremers 654 University of Oxford 655 cas.cremers@cs.ox.ac.uk 657 o Thyla van der Merwe 658 Royal Holloway, University of London 659 thyla.van.der@merwe.tech 661 o Jon Millican 662 Facebook 663 jmillican@fb.com 665 o Raphael Robert 666 Wire 667 raphael@wire.com 669 6. Informative References 671 [I-D.ietf-tls-tls13] 672 Rescorla, E., "The Transport Layer Security (TLS) Protocol 673 Version 1.3", draft-ietf-tls-tls13-28 (work in progress), 674 March 2018. 676 [KeyTransparency] 677 Google, ., "Key Transparency", n.d., 678 . 680 [MLSPROTO] 681 Barnes, R., Millican, J., Omara, E., Cohn-Gordon, K., and 682 R. Robert, "Messaging Layer Security Protocol", 2018. 684 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 685 Text on Security Considerations", BCP 72, RFC 3552, 686 DOI 10.17487/RFC3552, July 2003, 687 . 689 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 690 Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, 691 March 2011, . 693 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 694 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 695 October 2013, . 697 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 698 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 699 2014, . 701 Authors' Addresses 703 Emad Omara 704 Google 706 Email: emadomara@google.com 708 Benjamin Beurdouche 709 INRIA 711 Email: benjamin.beurdouche@inria.fr 712 Eric Rescorla 713 Mozilla 715 Email: ekr@rtfm.com 717 Srinivas Inguva 718 Twitter 720 Email: singuva@twitter.com 722 Albert Kwon 723 MIT 725 Email: kwonal@mit.edu 727 Alan Duric 728 Wire 730 Email: alan@wire.com