idnits 2.17.1 draft-muffett-end-to-end-secure-messaging-03.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (12 July 2021) is 1019 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-11) exists of draft-knodel-e2ee-definition-00 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 individual submission A. Muffett 3 Internet-Draft Security Researcher 4 Intended status: Informational 12 July 2021 5 Expires: 13 January 2022 7 A Duck Test for End-to-End Secure Messaging 8 draft-muffett-end-to-end-secure-messaging-03 10 Abstract 12 This document defines End-to-End Secure Messaging in terms of 13 behaviours that MUST be exhibited by software that claims to 14 implement it, or which claims to implement that subset which is known 15 as End-to-End Encrypted Messaging. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on 13 January 2022. 34 Copyright Notice 36 Copyright (c) 2021 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 41 license-info) in effect on the date of publication of this document. 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. Code Components 44 extracted from this document must include Simplified BSD License text 45 as described in Section 4.e of the Trust Legal Provisions and are 46 provided without warranty as described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1. Comments . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.2. Notational Conventions . . . . . . . . . . . . . . . . . 3 53 2. Requirements for an End-to-End Secure Messenger . . . . . . . 4 54 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3.1. Message and Platform . . . . . . . . . . . . . . . . . . 5 56 3.2. Plaintext Content and Sensitive Metadata (PCASM) . . . . 5 57 3.2.1. Content PCASM . . . . . . . . . . . . . . . . . . . . 5 58 3.2.2. Size PCASM . . . . . . . . . . . . . . . . . . . . . 5 59 3.2.3. Analytic PCASM . . . . . . . . . . . . . . . . . . . 5 60 3.2.4. Conversation Metadata (OPTIONAL) . . . . . . . . . . 5 61 3.3. Entity . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 3.4. Sender and Recipient . . . . . . . . . . . . . . . . . . 6 63 3.5. Participants and Non-Participants . . . . . . . . . . . . 6 64 3.6. Conversation, Group, Centralised & Decentralised . . . . 6 65 3.7. Backdoor . . . . . . . . . . . . . . . . . . . . . . . . 7 66 4. Principles . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 4.1. Transparency of Participation . . . . . . . . . . . . . . 7 68 4.2. Integrity of Participation . . . . . . . . . . . . . . . 7 69 4.2.1. Retransmission Exception . . . . . . . . . . . . . . 7 70 4.3. Equality of Participation . . . . . . . . . . . . . . . . 8 71 4.4. Closure of Conversation . . . . . . . . . . . . . . . . . 8 72 4.4.1. Public Conversations and Self-Subscription . . . . . 8 73 4.5. Management of Participant Clients and Devices . . . . . . 8 74 5. Rationales . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 5.1. Why: Content PCASM . . . . . . . . . . . . . . . . . . . 8 76 5.2. Why: Size PCASM . . . . . . . . . . . . . . . . . . . . . 9 77 5.3. Why: Analytic PCASM . . . . . . . . . . . . . . . . . . . 9 78 5.4. Why: Conversation Metadata as OPTIONAL PCASM . . . . . . 9 79 5.5. Why: Entity and Participant . . . . . . . . . . . . . . . 9 80 5.6. Why: Backdoor . . . . . . . . . . . . . . . . . . . . . . 10 81 5.7. Why: Transparency of Participation . . . . . . . . . . . 11 82 5.8. Why: Integrity of Participation . . . . . . . . . . . . . 11 83 5.9. Why: Equality of Participation . . . . . . . . . . . . . 11 84 5.10. Why: Closure of Conversation . . . . . . . . . . . . . . 12 85 5.11. Why: Management of Participant Clients and Devices . . . 12 86 6. OPTIONAL Features of E2ESM . . . . . . . . . . . . . . . . . 12 87 6.1. Disappearing Messages . . . . . . . . . . . . . . . . . . 12 88 6.2. Mutual Identity Verification . . . . . . . . . . . . . . 13 89 7. Examples of PCASM . . . . . . . . . . . . . . . . . . . . . . 13 90 7.1. Content PCASM . . . . . . . . . . . . . . . . . . . . . . 13 91 7.2. Size PCASM . . . . . . . . . . . . . . . . . . . . . . . 13 92 7.3. Analytic PCASM . . . . . . . . . . . . . . . . . . . . . 14 93 7.4. Conversation Metadata as OPTIONAL PCASM . . . . . . . . . 14 94 7.5. Non-PCASM . . . . . . . . . . . . . . . . . . . . . . . . 14 95 8. Worked Example . . . . . . . . . . . . . . . . . . . . . . . 15 96 9. See Also . . . . . . . . . . . . . . . . . . . . . . . . . . 15 97 10. Live Drafts . . . . . . . . . . . . . . . . . . . . . . . . . 16 98 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 99 12. Security Considerations . . . . . . . . . . . . . . . . . . . 16 100 13. Informative References . . . . . . . . . . . . . . . . . . . 16 101 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 103 1. Introduction 105 End-to-End Secure Messaging (E2ESM) is a mechanism which offers a 106 digital analogue of "closed distribution lists" for sharing message 107 content amongst a set of participants, where all participants are 108 visible to each other and where non-participants are completely 109 excluded from access to message content. 111 In client-server-client network models it is common to implement 112 E2ESM by means of encryption, in order to obscure content at rest 113 upon a central server. So therefore E2ESM is often narrowly regarded 114 in terms of "end-to-end encryption". 116 Other architectural approaches exist - for instance [Ricochet] which 117 implements closed distribution by using secure point-to-point 118 [RFC7686] networking to literally restrict the distribution of 119 content to relevant participants. 121 Therefore we describe E2ESM in terms of functional behaviours of the 122 software rather than in terms of its implementation technologies and 123 architecture. 125 1.1. Comments 127 Comments are solicited and should be addressed to the working group's 128 mailing list and/or the author(s). 130 1.2. Notational Conventions 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 134 "OPTIONAL" in this document are to be interpreted as described in BCP 135 14 [RFC2119] [RFC8174] when, and only when, they appear in all 136 capitals, as shown here. 138 2. Requirements for an End-to-End Secure Messenger 140 Software which functions as an End-to-End Secure Messenger MUST 141 satisfy the following principles, and MUST satisfy these principles 142 in respect of the provided definitions for all forms of communication 143 and data-sharing that the software offers. The E2ESM software MAY 144 comprise either a complete application, or a clearly defined subset 145 of functionality within a larger application. 147 Any software that does not satisfy these requirements is not an End- 148 to-End Secure Messenger, and it does not implement End-to-End Secure 149 Messaging, nor does it implement End-to-End Encrypted Messaging. 151 3. Definitions 153 These definitions are drafted in respect of many examples of software 154 commonly held to offer (or have offered) end-to-end security; these 155 examples include: 157 1. Signal Messenger 159 2. WhatsApp Messenger 161 3. Ricochet Messenger 163 4. PGP-Encrypted Email sent to an ad-hoc list of addressees, or to a 164 maillist 166 Further context for several of these definitions can also be found in 167 the rationales section, below. 169 For the avoidance of doubt we define a "messenger" as a software 170 solution which enables communication between two or more entities, 171 without offering newly-added participants retrospective access to 172 content which was previously sent by prior participants. 174 This echoes the distinction between a "maillist" versus a "maillist 175 archive" or "web forum"; frequently these solutions are integrated 176 but we only consider the maillist as a "messenger" per se. 178 Use cases of a "messenger" may include sending and receiving any or 179 all of: 181 1. UNICODE or ASCII messages 183 2. images, video files or audio files 185 3. one-way streaming video or audio 186 4. two-way streaming video or audio, as in live calls 188 3.1. Message and Platform 190 A "message" is information of 0 or more bits, to be communicated. 192 Messages possess both plaintext "content", and also "metadata" which 193 describes the content. 195 A "platform" is a specific instance of software which exists for the 196 purpose of routing or exchanging messages. 198 3.2. Plaintext Content and Sensitive Metadata (PCASM) 200 The "PCASM" of a message is defined as the "plaintext content and 201 sensitive metadata" of that message, comprising any or all of: 203 3.2.1. Content PCASM 205 Content PCASM is any data that can offer better than 50-50 certainty 206 regarding the value of any bit of the content. See "Rationales" for 207 more. 209 3.2.2. Size PCASM 211 For block encryption of content, Size PCASM is the unpadded size of 212 the content. 214 For stream encryption of content, Size PCASM is currently undefined. 215 (TODO, would benefit from broader input.) 217 For transport encryption of content, exact Size PCASM SHOULD NOT be 218 observable or inferable. 220 See "Rationales" for more. 222 3.2.3. Analytic PCASM 224 Analytic PCASM is data which analyses, describes, reduces, or 225 summarises the "content". See "Rationales" for more. 227 3.2.4. Conversation Metadata (OPTIONAL) 229 Conversation Metadata MAY exist "outside" of messages and describe 230 the conversation context. 232 Whether conversation metadata constitutes PCASM, is an OPTIONAL 233 choice for E2ESM software, but that choice MUST be apparent to 234 participants. 236 See "Rationales" for more. 238 3.3. Entity 240 An "entity" is a human, machine, software bot, conversation archiver, 241 or other, which sends and/or receives messages. 243 Entities are bounded by the extent of their Trusted Computing Base 244 ("TCB"), including all systems that they control and/or utilise. 246 3.4. Sender and Recipient 248 A "sender" is an entity which composes and sends messages. 250 A "recipient" is an entity which receives messages and MAY be able to 251 access the PCASM of those messages. 253 For each message there will be one sender and one or more recipients. 255 3.5. Participants and Non-Participants 257 The union set of sender and recipients for any given message are the 258 "participants" in that message. 260 It follows that for any given message, all entities that exist 261 outside of the participant set will be "non-participants" in respect 262 of that message. 264 3.6. Conversation, Group, Centralised & Decentralised 266 A "conversation" is a sequence of one or more messages, and the 267 responses or replies to them, over a period of time, amongst a 268 constant or evolving set of participants. 270 A given platform MAY distinguish between and support more than one 271 conversation at any given time. 273 In "centralised" E2ESM such as WhatsApp or Signal, the software MAY 274 offer collective "group" conversation contexts that provide 275 prefabricated sets of recipients for the client to utilise when a 276 message is composed or sent. 278 In "decentralised" E2ESM such as PGP-Encrypted Email or Ricochet the 279 recipients of each message are individually determined by each sender 280 at the point of composition; however "group" metadata may also exist, 281 in terms of (e.g.) email addressees or subject lines. 283 3.7. Backdoor 285 A "backdoor" is any intentional or unintentional mechanism, in 286 respect of a given message and that message's participants, where 287 some PCASM of that message MAY become available to a non-participant 288 without the intentional action of a participant. 290 4. Principles 292 For a series of one or more "messages" each which are composed of 293 "plaintext content and sensitive metadata" (PCASM) and which 294 constitute a "conversation" amongst a set of "participants", to 295 provide E2ESM will require: 297 4.1. Transparency of Participation 299 In the nature of "closed distribution lists", the participants in a 300 message MUST be frozen into an immutable set at the moment when the 301 message is composed or sent. 303 The complete set of all recipients MUST be visible to the sender at 304 the moment of message composition or sending. 306 The complete set of participants in a message MUST be visible to all 307 other participants. 309 4.2. Integrity of Participation 311 Excusing the "retransmission exception", PCASM of any given message 312 MUST only be available to the fixed set of conversation participants 313 from whom, to whom, and at the time when it was sent. 315 4.2.1. Retransmission Exception 317 If a participant that can access an "original" message intentionally 318 "retransmits" (e.g. quotes, forwards) that message to create a new 319 message within the E2ESM software, then the original message's PCASM 320 MAY become available to a new, additional, and possibly different set 321 of conversation participants, via that new message. 323 4.3. Equality of Participation 325 All participants MUST be peers, i.e. they MUST have equal access to 326 the PCASM of any message; see also "Integrity of Participation". 328 4.4. Closure of Conversation 330 The set of participants in a conversation SHALL NOT be increased 331 except by the intentional action of one or more existing 332 participants. 334 Per "Transparency of Participation" that action (introducing a new 335 participant) MUST be visible to all other participants 337 4.4.1. Public Conversations and Self-Subscription 339 Existing participants MAY publicly share links to the conversation, 340 identifying data to assist discovery of the conversation, or other 341 mechanisms to enable non-participant entities to subscribe themselves 342 as conversation participants. This MAY be considered legitimate 343 "intentional action" to increase the set of participants in the 344 group. 346 4.5. Management of Participant Clients and Devices 348 Where there exists centralised E2ESM software that hosts 349 participants: 351 1. The E2ESM software MUST provide each participant entity with 352 means to review or revoke access for that participant's clients 353 or devices that can access future PCASM. 355 2. The E2ESM software MUST provide each participant entity with 356 notifications and/or complete logs of changes to the set of 357 clients or devices that can or could access message PCASM. 359 5. Rationales 361 This explanatory section regarding the principles has been broken out 362 for clarity and argumentation purposes. 364 5.1. Why: Content PCASM 366 Content PCASM MUST be protected as it comprises that which is 367 "closed" from general distribution. 369 The test for measuring this is (intended to be) modeled upon 370 ciphertext indistinguishability [CipherInd] 372 5.2. Why: Size PCASM 374 Exact size PCASM MUST be protected as it MAY offer insight into 375 Content PCASM. 377 The test for measuring this is (intended) to address risk of content 378 becoming evident via plaintext length. 380 5.3. Why: Analytic PCASM 382 Analytic PCASM MUST be protected as it MAY offer insight into Content 383 PCASM, for instance that the content shares features with other, 384 specimen, or known plaintext content. 386 5.4. Why: Conversation Metadata as OPTIONAL PCASM 388 Conversational Metadata MAY offer insight into Content PCASM, however 389 the abstractions of transport mechanism, group management, or 390 platform choice, MAY render this moot. 392 For example an PGP-Encrypted email distribution list named 393 "blockchain-fans@example.com" would leak its implicit topic and 394 participant identities to capable observers. 396 5.5. Why: Entity and Participant 398 The term "participant" in this document exists to supersede the more 399 vague notion of "end" in the phrase "end-to-end". 401 Entities, and thus participants, are defined in terms of their 402 [TrustedComputingBase] to acknowledge that an entity MAY legitimately 403 store, forward, or access messages by means that are outside of the 404 E2ESM software. 406 It is important to note that the concept of "entity" as defined by 407 their TCB, is the foundation for all other trust in E2ESM. This 408 develops from the basic definitions of a [TrustedComputingBase] and 409 from the concepts of "trust-to-trust" discussed in [RoleOfTrust]. 410 Failure of a participant to maintain integrity or control over their 411 TCB should not be considered a failure of an E2ESM that connects it 412 to other participants. 414 For example: if a participant accesses their E2ESM software via 415 remote desktop software, and their RDP session is hijacked by a third 416 party; of if they back-up their messages in cleartext to cloud 417 storage leading somehow to data exfiltration, neither of these would 418 be a failure of E2ESM. This would instead be a failure of the 419 participant's [TrustedComputingBase]. 421 Further: it would be obviously possible to burden an E2ESM with 422 surfacing potential integrity issues of any given participant to 423 other participants, e.g. "patch compliance". But to require such in 424 this standard would risk harming the privacy of the participant 425 entity. See also: "Mutual Identity Verification" in "OPTIONAL 426 Features of E2ESM" 428 5.6. Why: Backdoor 430 In software engineering there is a perpetual tension between the 431 concepts of "feature" versus "bug" - and occasionally "misfeature" 432 versus "misbug". These tensions arise from the problem of [DualUse] 433 - that it is not feasible to firmly and completely ascribe 434 "intention" to any hardware or software mechanism. 436 The information security community has experienced a historical 437 spectrum of mechanisms which have assisted non-participant access to 438 PCASM. These have variously been named as "export-grade key 439 restrictions" ([ExportControl], then [Logjam]), "side channel 440 attacks" ([Spectre] and [Meltdown]), "law enforcement access fields" 441 [Clipper], and "key escrow" [CryptoWars]. 443 All of these terms combine an "access facilitation mechanism" with an 444 "intention or opportunity" - and for all of them an access 445 facilitation mechanism is first REQUIRED. 447 An access facilitation mechanism is a "door", and is inherently 448 [DualUse]. Because the goal of E2ESM is to limit access to PCASM 449 exclusively to a defined set of participants, then the intended means 450 of access is clearly the "front door"; and any other access mechanism 451 is a "back door". 453 If the term "back door" is considered innately pejorative, 454 alternative, uncertain constructions such as "illegitimate access 455 feature", "potentially intentional data-access weakness", "legally- 456 obligated exceptional access mechanism", or any other phrase, all 457 MUST combine both notions of an access mechanism (e.g. "door") and a 458 definite or suspected intention (e.g. "legal obligation"). 460 So the phrase "back door" is brief, clear, and widely understood to 461 mean "a secondary means of access". In the above definition we 462 already allow for the term to be prefixed with "intentional" or 463 "unintentional". 465 Thus it seems appropriate to use this term in this context, not least 466 because it is also not far removed from the similar and established 467 term "side channel". 469 5.7. Why: Transparency of Participation 471 The "ends" of "end to end" are the participants; for a message to be 472 composed to be exclusively accessible to that set of participants, 473 all participants must be visible. 475 For decentralised "virtual point-to-point" E2ESM solutions such as 476 PGP-Encrypted Email or Ricochet, the set of participants is fixed by 477 the author at the time of individual message composition, and MUST be 478 visible to all participants. 480 For "centralised" E2ESM solutions such as Signal or WhatsApp, the set 481 of participants is a "group context" shared amongst all participants 482 and at the time of individual message composition it MUST be 483 inherited into a set of "fixed" per-participant access capabilities 484 by the author. 486 5.8. Why: Integrity of Participation 488 Inherent in the term "end to end secure messenger" is the intention 489 that PCASM will only be available to the participants ("ends") at the 490 time the message was composed. 492 If this was not the intention we would deduce that an E2ESM would 493 automatically make past content available to newly-added conversation 494 participants, thereby breaking forward secrecy. This is not a 495 characteristic of any E2ESM, but it is characteristic of several non- 496 E2ESM. Therefore the converse is true. 498 As a concrete example this means that participants who are newly 499 added to a "group" MUST NOT be able to read messages that were sent 500 before they joined that group - unless (for instance) one pre- 501 existing participant is explicitly intended to provide a "searchable 502 archive" or similar function. The function of such a participant is 503 considered to be out of scope for the messenger. 505 5.9. Why: Equality of Participation 507 Without equality of participation it would be allowed for a person to 508 deploy a standalone cleartext chat server, available solely over TLS- 509 encrypted links, declare themselves to be "participants" in every 510 conversation from its outset, access all message PCASM on that basis, 511 and yet call themselves an E2ESM. 513 So this is an "anti-cheating" clause: all participant access to PCASM 514 MUST be via the same mechanisms for all participants without favour 515 or privilege, and in particular PCASM MUST NOT be available via other 516 means, e.g. raw block-device access, raw filestore, raw database 517 access, or network sniffing. 519 5.10. Why: Closure of Conversation 521 If a conversation is not "only extensible from within" then it would 522 be possible for participants to be injected into the conversation 523 thereby defeating the closure of message distribution. 525 A subtle centralised vs: decentralised edge-case is as follows: 526 consider a PGP-encrypted email distribution list. Would it break 527 "closure of conversation" for a non-participant email administrator 528 to simply add new users to the maillist? 530 Answer: no, because in this case the maillist is functioning as a 531 "platform" for multiple "conversation" threads, and mere addition of 532 of a new "transport-level" maillist member would not include them as 533 a participant in ongoing E2ESM conversations; such inclusion would be 534 a future burden upon existing participants. 536 However: similar external injection of a new entity into a 537 centralised WhatsApp or Signal "group" would be clearly a breach of 538 "closure of conversation". 540 5.11. Why: Management of Participant Clients and Devices 542 There is little benefit in requiring conversations to be closed 543 against "participant injection" if a non-participant may obtain PCASM 544 access by forcing a platform to silently add extra means of PCASM 545 access to an existing participant on behalf of that non-participant. 547 Therefore to be an E2ESM the platform MUST provide the described 548 management of participant clients and devices. 550 6. OPTIONAL Features of E2ESM 552 6.1. Disappearing Messages 554 "Disappearing", "expiring", "exploding", "ephemeral" or other forms 555 of time-limited access to PCASM are strongly RECOMMENDED but not 556 obligatory mechanisms for E2ESM, not least because they are 557 impossible to implement in a way that cannot be circumvented by e.g. 558 screenshots. 560 6.2. Mutual Identity Verification 562 Some manner of "shared key" which mutually assures participant 563 identity and communications integrity are strongly RECOMMENDED but 564 not obligatory mechanisms for E2ESM. 566 The benefits of such mechanisms are limited to certain perspectives 567 of certain platforms. 569 For instance: in Ricochet the identity key of a user is the absolute 570 source of truth for their identity, and excusing detection of 571 typographic errors there is nothing which can be added to that in 572 order to further assure their "identity". 574 Similarly WhatsApp provides each participant with a "verifiable 575 security QR code" and "security code change notifications", but these 576 codes do not "leak" the number of "WhatsApp For Web" connections, 577 desktop WhatsApp applications, or other clients which are bound to 578 the E2ESM software which executes on that phone. 580 Participant-client information of this kind MAY be a highly private 581 aspect of that participant's TCB, and SHOULD be treated sensitively 582 by platforms. 584 7. Examples of PCASM 586 For an example message with content ("content") of "Hello, world.", 587 for the purposes of this example encoded as an ASCII string of length 588 13 bytes without terminator character. 590 7.1. Content PCASM 592 Examples of Content PCASM would include, non-exclusively: 594 1. The content is "Hello, world." 596 2. The content starts with the word "Hello" 598 3. The top bit of the first byte of the content, is zero 600 4. The MD5 hash of the content is 080aef839b95facf73ec599375e92d47 602 5. The Salted-MD5 Hash of the content is : ... 604 7.2. Size PCASM 606 Size PCASM is defined in the main text, as it relates to the 607 transport and/or content encryption mechanisms. 609 7.3. Analytic PCASM 611 Examples of Analytic PCASM would include, non-exclusively: 613 1. The content contains the substring "ello" 615 2. The content does not contain the word "Goodbye" 617 3. The content contains a substring from amongst the following set: 618 ... 620 4. The content does not contain a substring from amongst the 621 following set: ... 623 5. The hash of the content exists amongst the following set of 624 hashes: ... 626 6. The hash of the content does not exist amongst the following set 627 of hashes: ... 629 7. The content was matched by a machine-learning classifier with the 630 following training set: ... 632 7.4. Conversation Metadata as OPTIONAL PCASM 634 Examples of Conversation Metadata would include, non-exclusively: 636 1. maillist email addresses 638 2. maillist server names 640 3. group titles 642 4. group topics 644 5. group icons 646 6. group participant lists 648 7.5. Non-PCASM 650 Information which would not be PCASM would include, non-exclusively: 652 1. The content is sent from Alice 654 2. The content is sent to Bob 656 3. The content is between 1 and 16 bytes long 657 4. The content was sent at the following date and time: ... 659 5. The content was sent from the following IP address: ... 661 6. The content was sent from the following geolocation: ... 663 7. The content was composed using the following platform: ... 665 8. Worked Example 667 Consider FooBook, a hypothetical example company which provides 668 messaging services for conversations between entities who use it. 670 For each conversation FooBook MUST decide whether to represent itself 671 as a conversation participant or as a non-participant. (Transparency 672 of Participation) 674 If FooBook decides to represent itself as a non-participant, then it 675 MUST NOT have any access to PCASM. (Integrity of Participation / 676 Non-Participation) 678 If FooBook decides to represent itself as a participant, then it MUST 679 NOT have "exceptional" access to PCASM, despite being the provider of 680 the service - for instance via raw database access or network 681 sniffing. However it MAY participate in E2ESM conversations in a 682 "normal" way, and thereby have "normal" access to intra-conversation 683 PCASM. (Integrity of Participation, Equality of Participation) 685 FooBook MAY retain means to eject reported abusive participants from 686 a conversation. (Decrease in Closure of Participation) 688 FooBook MUST NOT retain means to forcibly insert new participants 689 into a conversation. For clarity: this specification does not 690 recognise any notion of "atomic" exchange of one participant with 691 another, treating it as an ejection, followed by an "illegitimate" 692 insertion. (Increase in Closure of Participation) 694 FooBook MUST enable the user to observe and manage the complete state 695 of their [TrustedComputingBase] with respect to their FooBook 696 messaging services. (Management and Visibility) 698 FooBook MAY treat conversation metadata as PCASM, but it MUST 699 communicate to participants whether it does or does not. 701 9. See Also 703 A different approach to defining (specifically) end-to-end encryption 704 is discussed in [I-D.knodel-e2ee-definition]. 706 10. Live Drafts 708 Live working drafts of this document are at: 709 https://github.com/alecmuffett/draft-muffett-end-to-end-secure- 710 messaging (https://github.com/alecmuffett/draft-muffett-end-to-end- 711 secure-messaging) 713 11. IANA Considerations 715 This document has no IANA actions. 717 12. Security Considerations 719 This document is entirely composed of security considerations. 721 13. Informative References 723 [CipherInd] 724 Wikipedia, "Ciphertext indistinguishability", 2021, 725 . 728 [Clipper] Wikipedia, "Clipper chip", 2021, 729 . 731 [CryptoWars] 732 Wikipedia, "Crypto Wars", 2021, 733 . 735 [DualUse] Wikipedia, "Dual-use technology", 2021, 736 . 738 [ExportControl] 739 Wikipedia, "Export of cryptography from the United 740 States", 2021, . 743 [I-D.knodel-e2ee-definition] 744 Knodel, M., Baker, F., Kolkman, O., Celi, S., and G. 745 Grover, "Definition of End-to-end Encryption", Work in 746 Progress, Internet-Draft, draft-knodel-e2ee-definition-00, 747 22 February 2021, . 750 [Logjam] Wikipedia, "Logjam", 2021, . 753 [Meltdown] Wikipedia, "Meltdown", 2021, 754 . 757 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 758 Requirement Levels", BCP 14, RFC 2119, 759 DOI 10.17487/RFC2119, March 1997, 760 . 762 [RFC7686] Appelbaum, J. and A. Muffett, "The ".onion" Special-Use 763 Domain Name", RFC 7686, DOI 10.17487/RFC7686, October 764 2015, . 766 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 767 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 768 May 2017, . 770 [Ricochet] BlueprintForFreeSpeech, "Ricochet Refresh", 2021, 771 . 773 [RoleOfTrust] 774 Clark, D. D. and M. S. Blumenthal, "The End-to-End 775 Argument and Application Design: The Role of Trust", 2011, 776 . 779 [Spectre] Wikipedia, "Spectre", 2021, 780 . 783 [TrustedComputingBase] 784 Wikipedia, "Trusted Computing Base", 2021, 785 . 787 Author's Address 789 Alec Muffett 790 Security Researcher 792 Email: alec.muffett@gmail.com