idnits 2.17.1 draft-omara-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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (February 07, 2018) is 2262 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 675, but no explicit reference was found in the text == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-23 -- Obsolete informational reference (is this intentional?): RFC 3920 (Obsoleted by RFC 6120) -- 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 (~~), 4 warnings (==), 4 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: August 11, 2018 INRIA 6 E. Rescorla 7 Mozilla 8 S. Inguva 9 Twitter 10 A. Kwon 11 MIT 12 A. Duric 13 Wire 14 February 07, 2018 16 Messaging Layer Security Architecture 17 draft-omara-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 August 11, 2018. 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 . . . . . . . . . . . . . . . . . . . . . 8 72 3.1. Functional Requirements . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . 13 87 4.4. Client Compromise . . . . . . . . . . . . . . . . . . . . 14 88 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 89 6. Informative References . . . . . . . . . . . . . . . . . . . 14 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 92 1. Introduction 94 End-to-end security is a requirement for instant messaging systems 95 and is commonly deployed in many such systems. In this context, 96 "end-to-end" captures the notion that users of the system enjoy some 97 level of security - with the precise level depending on the system 98 design - even when the messaging service they are using performs 99 unsatisfactorily. 101 Messaging Layer Security (MLS) specifies an architecture (this 102 document) and an abstract protocol [MLSPROTO] for providing end-to- 103 end security in this setting. MLS is not intended as a full instant 104 messaging protocol but rather is intended to be embedded in a 105 concrete protocol such as XMPP [RFC3920]. In addition, it does not 106 specify a complete wire encoding, but rather a set of abstract data 107 structures which can then be mapped onto a variety of concrete 108 encodings, such as TLS [I-D.ietf-tls-tls13], CBOR [RFC7049], and JSON 109 [RFC7159]. Implementations which adopt compatible encodings should 110 be able to have some degree of interoperability at the message level, 111 though they may have incompatible identity/authentication 112 infrastructures. 114 This document is intended to describe the overall messaging system 115 architecture which the MLS protocol fits into, and the requirements 116 which it is intended to fulfill. 118 2. General Setting 120 A Group using a Messaging Service (MS) comprises a set of 121 participants called Members where each Member is typically expected 122 to own multiple devices, called Clients. A group may be as small as 123 two members (the simple case of person to person messaging) or as 124 large as thousands. In order to communicate securely, Group Members 125 initially use services at their disposal to obtain the necessary 126 secrets and credentials required for security. 128 The Messaging Service (MS) presents as two abstract services that 129 allow Members to prepare for sending and receiving messages securely: 131 o An Authentication Service (AS) which is responsible for 132 maintaining user long term identities, issuing credentials which 133 allow them to authenticate each other, and potentially allowing 134 users to discover each others long-term identity keys. 136 o A Delivery Service (DS) which is responsible for receiving and 137 redistributing messages between group members. In the case of 138 group messaging, the delivery service may also be responsible for 139 acting as a "broadcaster" where the sender sends a single message 140 to a group which is then forwarded to each recipient in the group 141 by the DS. The DS is also responsible for storing and delivering 142 initial public key material required in order to proceed with the 143 group secret key establishment process. 145 ---------------- -------------- 146 | Authentication | | Delivery | 147 | Service (AS) | | Service (DS) | 148 ---------------- -------------- 149 / | \ Group 150 ********************************************************* 151 * / | \ * 152 * / | \ * 153 * ---------- ---------- ---------- * 154 * | Client 0 | | Client 1 | | Client N | * 155 * ---------- ---------- ---------- * 156 * ............................ ........... * 157 * Member 0 Member 1 * 158 * * 159 ********************************************************* 161 In many systems, the AS and the DS are actually operated by the same 162 entity and may even be the same server. However, they are logically 163 distinct and, in other systems, may be operated by different 164 entities, hence we show them as being separate here. Other 165 partitions are also possible, such as having a separate directory 166 server. 168 A typical group messaging scenario might look like this: 170 1. Alice, Bob and Charlie create accounts with a messaging service 171 and obtain credentials from the AS. 173 2. Alice, Bob and Charlie authenticate to the DS and store some 174 initial keying material which can be used to send encrypted 175 messages to them for the first time. This keying material is 176 authenticated with their long term credentials. 178 3. When Alice wants to send a message to Bob and Charlie, she 179 contacts the DS and looks up their initial keying material. She 180 uses these keys to establish a new set of keys which she can use 181 to send encrypted messages to Bob and Charlie. She then sends 182 the encrypted message(s) to the DS, which forwards them to the 183 recipients. 185 4. Bob and/or Charlie respond to Alice's message. Their messages 186 might trigger a new key derivation step which allows the shared 187 group key to be updated to provide post-compromise security 188 Section 3.2.2.1. 190 Clients may wish to do the following: 192 o create a group by inviting a set of other members; 194 o add one or more members to an existing group; 196 o remove one or more members from an existing group; 198 o join an existing group; 200 o leave a group; 202 o send a message to everyone in the group; 204 o receive a message from someone in the group. 206 At the cryptographic level, Clients in groups (and by extension 207 Members) are peers. For instance, any Client should be able to add a 208 member to a group. This is in contrast so some designs in which 209 there is a single group controller who can modify the group. MLS is 210 compatible with having group administration restricted to certain 211 users, but we assume that those restrictions are enforced by 212 authentication and access control. Thus, for instance, while it 213 might be technically possible for any member to send a message adding 214 a new member to a group, the group might have the policy that only 215 certain members are allowed to make changes and thus other members 216 can ignore or reject such a message from an unauthorized user. 218 2.1. Group, Members and Clients 220 In MLS a Group is defined as a set of Members who possibly use 221 multiple endpoint devices (Clients) to interact with the Messaging 222 Service. These Clients will typically correspond to end-user devices 223 such as phones, web clients or other devices running MLS. 225 Each member device owns a long term identity key pair that uniquely 226 defines its identity to other Members of the Group. Because a single 227 Member may operate multiple devices simultaneously (e.g., a desktop 228 and a phone) or sequentially (e.g., replacing one phone with 229 another), the formal definition of a Group in MLS is the set of 230 Clients that has legitimate knowledge of the shared (Encryption) 231 Group Key established in the group key establishment phase of the 232 protocol. 234 In some messaging systems, Clients belonging to the same Member must 235 all share the same identity key pair, but MLS does not assume this. 236 The MLS architecture considers the more general case and allows for 237 important use cases, such as a Member adding a new Client when all 238 their existing clients are offline. 240 MLS has been designed to provide similar security guarantees to all 241 Clients, for all group sizes, even when it reduces to only two 242 Clients. 244 2.2. Authentication Service 246 The basic function of the Authentication Service is to provide a 247 trusted mapping from user identities (usernames, phone numbers, 248 etc.), which exist 1:1 with Members, to identity keys, which may 249 either be one per Client or may be shared amongst the Clients 250 attached to a Member. 252 o A certificate authority or similar service which signs some sort 253 of portable credential binding an identity to a key. 255 o A directory server which provides the key for a given identity 256 (presumably this connection is secured via some form of transport 257 security such as TLS). 259 By definition, the AS is invested with a large amount of trust. A 260 malicious AS can impersonate - or allow an attacker to impersonate - 261 any user of the system. This risk can be mitigated by publishing the 262 binding between identities and keys in a public log such as Key 263 Transparency (KT) [KeyTransparency]. It is possible to build a 264 functional MLS system without any kind of public key logging, but 265 such a system will necessarily be somewhat vulnerable to attack by a 266 malicious or untrusted AS. 268 2.3. Delivery Service 270 The Delivery Service (DS) is expected to play multiple roles in the 271 Messaging Service architecture: 273 o To act as a directory service providing the keying material 274 (authentication keys and initial keying material) for Clients to 275 use. This allows a Client to establish a shared key and send 276 encrypted messages to other Clients even if the other Client is 277 offline. 279 o To route messages between Clients and to act as a message 280 broadcaster, taking in one message and forwarding it to multiple 281 Clients (also known as "server side fanout") 283 Depending on the level of trust given by the Group to the Delivery 284 Service, the functional and security guarantees provided by MLS may 285 differ. 287 2.3.1. Key Storage 289 Upon joining the system, each Client stores its initial cryptographic 290 key material with the DS. This key material represents the initial 291 contribution from each member that will be used in the establishment 292 of the shared group key. This initial keying material MUST be 293 authenticated using the Client's identity key. Thus, the Client 294 stores: 296 o A credential from the Authentication service attesting to the 297 binding between the Member and the Client's identity key. 299 o The member's initial keying material signed with the Client's 300 identity key. 302 As noted above, Members may have multiple Clients, each with their 303 own keying material, and thus there may be multiple entries stored by 304 each Member. 306 2.3.2. Key Retrieval 308 When a Client wishes to establish a group and send an initial message 309 to that group, it contacts the DS and retrieves the initial key 310 material for each other Member, verifies it using the identity key, 311 and then is able to form a joint key with each other Client, and from 312 those forms the group key, which it can use for the encryption of 313 messages. 315 2.3.3. Delivery of messages and attachments 317 The DS's main responsibility is to ensure delivery of messages. 318 Specifically, we assume that DSs provide: 320 o Reliable delivery: when a message is provided to the DS, it is 321 eventually delivered to all group members. 323 o In-order delivery: messages are delivered to the group in the 324 order they are received from a given Client and in approximately 325 the order in which they are sent by Clients. The latter is an 326 approximate guarantee because multiple Clients may send messages 327 at the same time and so the DS needs some latitude in reordering 328 between Clients. 330 o Consistent ordering: the DS must ensure that all Clients have the 331 same view of message ordering. 333 Note that the DS may provide ordering guarantees by ensuring in-order 334 delivery or by providing messages with some kind of sequence 335 information and allowing clients to reorder on receipt. 337 The MLS protocol itself should be able to verify these properties. 338 For instance, if the DS reorders messages from a Client or provides 339 different Clients with inconsistent orderings, then Clients should be 340 able to detect this misconduct. However, MLS need not provide 341 mechanisms to recover from a misbehaving DS. 343 Note that some forms of DS misbehavior are still possible and 344 difficult to detect. For instance, a DS can simply refuse to relay 345 messages to and from a given Client. Without some sort of side 346 information, other Clients cannot generally distinguish this form of 347 Denial of Service (DoS) attack from the Client being actually 348 offline. 350 2.3.4. Membership knowledge 352 Group membership is itself sensitive information and MLS is designed 353 so that neither the DS nor the AS need have static knowledge of which 354 Clients are in which Group. However, they may learn this information 355 through traffic analysis. For instance, in a server side fanout 356 model, the DS learns that a given Client is sending the same message 357 to a set of other Clients. In addition, there may be applications of 358 MLS in which the Group membership list is stored on some server 359 associated with the MS. 361 2.3.5. Membership and offline members 363 Because Forward Secrecy (FS) and Post-Compromise Security (PCS) rely 364 on the deletion and replacement of keying material, any Client which 365 is persistently offline may still be holding old keying material and 366 thus be a threat to both FS and PCS if it is later compromised. MLS 367 doesn't inherently defend against this problem, but MLS-using systems 368 should enforce some mechanism for doing so. Typically this will 369 consist of evicting Clients which are idle for too long, thus 370 containing the threat of compromise. The precise details of such 371 mechanisms are a matter of local policy. 373 3. System Requirements 375 3.1. Functional Requirements 377 MLS is designed as a large scale group messaging protocol and hence 378 aims to provide performance and safety to its users. Messaging 379 systems that implement MLS must provide support for conversations 380 involving two or more participants, and aim to scale to approximately 381 50,000 clients, typically including many Members using multiple 382 devices. 384 3.1.1. Asynchronous Usage 386 No operation in MLS should require two distinct users to be online 387 simultaneously. In particular, clients participating in 388 conversations protected using MLS must be able to update shared keys, 389 add or remove new members, and send messages and attachments without 390 waiting for another user's reply. 392 Messaging systems that implement MLS must provide a transport layer 393 for delivering messages asynchronously and reliably. 395 3.1.2. Recovery After State Loss 397 Conversation participants whose local MLS state is lost or corrupted 398 must be able to reinitialize their state and continue participating 399 in the conversation. This may entail some level of message loss, but 400 should not result in permanent exclusion from the group. 402 3.1.3. Support for Multiple Devices 404 It is typically expected for Members of the Group to own different 405 devices. 407 A new device can join the group and will be considered as a new 408 Client by the protocol. This Client will not gain access to the 409 history even if it is owned by someone who is already a Member of the 410 Group. Restoring history is typically not allowed at the protocol 411 level but applications may elect to provide such a mechanism outside 412 of MLS. 414 3.1.4. Extensibility / Pluggability 416 Messages that don't affect the group state can carry an arbitrary 417 payload with the purpose of sharing that payload between group 418 members. No assumptions are made about the format of the payload. 420 3.1.5. Privacy 422 The protocol is designed in a way that limits the server-side (AS and 423 DS) metadata footprint. The DS must only persist data required for 424 the delivery of messages and avoid Personally Identifiable 425 Information (PII) or other sensitive metadata wherever possible. A 426 Messaging Service provider that has control over both the AS and the 427 DS, will not be able to correlate encrypted messages forwarded by the 428 DS, with the initial public keys signed by the AS. 430 3.1.6. Federation 432 The protocol aims to be compatible with federated environments. 433 While this document does not specify all necessary mechanisms 434 required for federation, multiple MLS implementations should be able 435 to interoperate and to form federated systems. 437 3.1.7. Compatibility with future versions of MLS 439 It is important the multiple versions of MLS be able to coexist in 440 the future. Thus, MLS must offer a version negotiation mechanism; 441 this mechanism must prevent version downgrade attacks where an 442 attacker would actively rewrite messages messages with a lower 443 protocol version than the ones originally offered by the endpoints. 444 When multiple versions of MLS are available, the negotiation protocol 445 must guarantee that the version agreed upon will be the highest 446 version supported in common by the group. 448 3.2. Security Requirements 450 3.2.1. Connections between Clients and Servers (one-to-one) 452 We assume that all transport connections are secured via some 453 transport layer security mechanism such as TLS [I-D.ietf-tls-tls13]. 454 However, as noted above, the security of MLS should generally survive 455 compromise of the transport layer. 457 3.2.2. Message Secrecy and Authentication 459 The trust establishment step of the MLS protocol is followed by a 460 conversation protection step where encryption is used by clients to 461 transmit authenticated messages to other clients through the DS. 462 This ensures that the DS doesn't have access to the Group's private 463 content. 465 MLS aims to provide Secrecy, Integrity and Authentication for all 466 messages. 468 Message Secrecy in the context of MLS means that only intended 469 recipients (current group members), should be able to read any 470 message sent to the group, even in the context of an active adversary 471 as described in the threat model. 473 Message Integrity and Authentication mean that an honest Client 474 should only accept a message if it was sent by a group member and 475 that one Client must not be able to send a message which other 476 Clients accept as being from another Client. 478 A corollary to this statement is that the AS and the DS can't read 479 the content of messages sent between Members as they are not Members 480 of the Group. MLS is expected to optionally provide additional 481 protections regarding traffic analysis so as to reduce the ability of 482 adversaries, or a compromised member of the messaging system, to 483 deduce the content of the messages depending on (for example) their 484 size. One of these protections includes padding messages in order to 485 produce ciphertexts of standard length. While this protection is 486 highly recommended it is not mandatory as it can be costly in terms 487 of performance for clients and the MS. 489 Message content can be deniable if the signature keys are exchanged 490 over a deniable channel prior to signing messages. 492 3.2.2.1. Forward and Post-Compromise Security 494 MLS provides additional protection regarding secrecy of past messages 495 and future messages. These cryptographic security properties are 496 Forward Secrecy (FS) and Post-Compromise Security (PCS). 498 FS means that access to all encrypted traffic history combined with 499 an access to all current keying material on clients will not defeat 500 the secrecy properties of messages older than the oldest key of the 501 client. Note that this means that clients have the extremely 502 important role of deleting appropriate keys as soon as they have been 503 used with the expected message, otherwise the secrecy of the messages 504 and the security for MLS is considerably weakened. 506 PCS means that if a group member is compromised at some time t but 507 subsequently performs an update at some time t', then all MLS 508 guarantees should apply to messages sent after time t'. For example, 509 if an adversary learns all secrets known to Alice at time t, 510 including both Alice's secret keys and all shared group keys, but 511 Alice performs a key update at time t', then the adversary should be 512 unable to violate any of the MLS security properties after time t'. 514 Both of these properties must be satisfied even against compromised 515 DSs and ASs. 517 3.2.2.2. Membership Changes 519 MLS aims to provide agreement on group membership, meaning that all 520 group members have agreed on the list of current group members. 522 Some applications may wish to enforce ACLs to limit addition or 523 removal of group members, to privileged users. Others may wish to 524 require authorization from the current group members or a subset 525 thereof. Regardless, MLS does not allow addition or removal of group 526 members without informing all other members. 528 Once a Member is part of a Group, the set of devices controlled by 529 the member should only be altered by an authorized member of the 530 group. This authorization could depend on the application: some 531 applications might want to allow certain other members of the group 532 to add or remove devices on behalf of another member, while other 533 applications might want a more strict policy and allow only the owner 534 of the devices to add or remove them at the potential cost of weaker 535 PCS guarantees. 537 Members who are removed from a group do not enjoy special privileges: 538 compromise of a removed group member should not affect the security 539 of messages sent after their removal. 541 3.2.2.3. Security of Attachments 543 The security properties expected for attachments in the MLS protocol 544 are very similar to the ones expected from messages. The distinction 545 between messages and attachments stems from the fact that the typical 546 average time between the download of a message and the one from the 547 attachments may be different. For many reasons (a typical reason 548 being the lack of high bandwidth network connectivity), the lifetime 549 of the cryptographic keys for attachments is usually higher than for 550 messages, hence slightly weakening the PCS guarantees for 551 attachments. 553 3.2.2.4. Denial of Service 555 In general we do not consider Denial of Service (DoS) resistance to 556 be the responsibility of the protocol. However, it should not be 557 possible for anyone to perform a trivial Denial of Service (DoS) 558 attack from which it is hard to recover. 560 3.2.2.5. Deniability 562 As described in Section 4.4, MLS aims to provide data origin 563 authentication within a group, such that one group member cannot send 564 a message that appears to be from another group member. 565 Additionally, it is a requirement of some services that a recipient 566 be able to prove to the messaging service that a message was sent by 567 a given Client, in order to report abuse. MLS should support both of 568 these use cases. In some deployments, these services may be provided 569 by mechanisms which allow the receiver to prove a message's origin to 570 a third party (this if often called "non-repudiation"), but it should 571 also be possible to operate MLS in a "deniable" mode where such proof 572 is not possible. [[OPEN ISSUE: Exactly how to supply this is still a 573 protocol question.]] 575 4. Security Considerations 577 MLS adopts the Internet threat model [RFC3552] and therefore assumes 578 that the attacker has complete control of the network. It is 579 intended to provide the security services described in in the face of 580 such attackers. In addition, these guarantees are intended to 581 degrade gracefully in the presence of compromise of the transport 582 security links as well as of both Clients and elements of the 583 messaging system, as described in the remainder of this section. 585 4.1. Transport Security Links 587 [TODO: Mostly DoS, message suppression, and leakage of group 588 membership.] 590 4.2. Delivery Service Compromise 592 MLS is intended to provide strong guarantees in the face of 593 compromise of the DS. Even a totally compromised DS should not be 594 able to read messages or inject messages that will be acceptable to 595 legitimate Clients. It should also not be able to undetectably 596 remove, reorder or replay messages. 598 However, a DS can mount a variety of DoS attacks on the system, 599 including total DoS attacks (where it simply refuses to forward any 600 messages) and partial DoS attacks (where it refuses to forward 601 messages to and from specific Clients). As noted in Section 2.3.3, 602 these attacks are only partially detectable by clients. Ultimately, 603 failure of the DS to provide reasonable service must be dealt with as 604 a customer service matter, not via technology. 606 Because the DS is responsible for providing the initial keying 607 material to Clients, it can provide stale keys. This doesn't 608 inherently lead to compromise of the message stream, but does allow 609 it to attack forward security to a limited extent. This threat can 610 be mitigated by having initial keys expire. 612 4.3. Authentication Service Compromise 614 A compromised AS is a serious matter, as the AS can provide incorrect 615 or adversarial identities to clients. As noted in Section 2.2, 616 mitigating this form of attack requires some sort of transparency/ 617 logging mechanism. Without such a mechanism, MLS will only provide 618 limited security against a compromised AS. 620 4.4. Client Compromise 622 In general, MLS only provides limited protection against compromised 623 Clients. When the Client is compromised, then the attacker will 624 obviously be able to decrypt any messages for groups in which the 625 Client is a member. It will also be able to send messages 626 impersonating the compromised Client until the Client updates its 627 keying material (see Section 3.2.2.1). MLS attempts to provide some 628 security in the face of client compromise. 630 In addition, a Client should not be able to send a message to a group 631 which appears to be from another Client with a different identity. 632 Note that if Clients from the same Member share keying material, then 633 one will be able to impersonate another. 635 Finally, Clients should not be able to perform denial of service 636 attacks Section 3.2.2.4. 638 5. Contributors 640 o Katriel Cohn-Gordon 641 University of Oxford 642 me@katriel.co.uk 644 o Cas Cremers 645 University of Oxford 646 cas.cremers@cs.ox.ac.uk 648 o Thyla van der Merwe 649 Royal Holloway, University of London 650 thyla.van.der@merwe.tech 652 o Jon Millican 653 Facebook 654 jmillican@fb.com 656 o Raphael Robert 657 Wire 658 raphael@wire.com 660 6. Informative References 662 [I-D.ietf-tls-tls13] 663 Rescorla, E., "The Transport Layer Security (TLS) Protocol 664 Version 1.3", draft-ietf-tls-tls13-23 (work in progress), 665 January 2018. 667 [KeyTransparency] 668 Google, ., "Key Transparency", n.d., 669 . 671 [MLSPROTO] 672 Barnes, R., Millican, J., Omara, E., Cohn-Gordon, K., and 673 R. Robert, "Messaging Layer Security Protocol", 2018. 675 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 676 Requirement Levels", BCP 14, RFC 2119, 677 DOI 10.17487/RFC2119, March 1997, 678 . 680 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 681 Text on Security Considerations", BCP 72, RFC 3552, 682 DOI 10.17487/RFC3552, July 2003, 683 . 685 [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence 686 Protocol (XMPP): Core", RFC 3920, DOI 10.17487/RFC3920, 687 October 2004, . 689 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 690 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 691 October 2013, . 693 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 694 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 695 2014, . 697 Authors' Addresses 699 Emad Omara 700 Google 702 Email: emadomara@google.com 704 Benjamin Beurdouche 705 INRIA 707 Email: benjamin.beurdouche@inria.fr 709 Eric Rescorla 710 Mozilla 712 Email: ekr@rtfm.com 713 Srinivas Inguva 714 Twitter 716 Email: singuva@twitter.com 718 Albert Kwon 719 MIT 721 Email: kwonal@mit.edu 723 Alan Duric 724 Wire 726 Email: alan@wire.com