idnits 2.17.1 draft-muffett-end-to-end-secure-messaging-00.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 (7 May 2021) is 1083 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 7 May 2021 5 Expires: 8 November 2021 7 Functional Definition of End-to-End Secure Messaging 8 draft-muffett-end-to-end-secure-messaging-00 10 Abstract 12 This document defines End-to-End Secure Messaging in terms of the 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 8 November 2021. 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 51 1.1. Comments . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.2. Notational Conventions . . . . . . . . . . . . . . . . . 3 53 2. Requirements for an End-to-End Secure Messenger . . . . . . . 3 54 3. Principles . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3.1. Equality of Participation . . . . . . . . . . . . . . . . 3 56 3.2. Transparency of Participation . . . . . . . . . . . . . . 4 57 3.3. Integrity of Participation . . . . . . . . . . . . . . . 4 58 3.3.1. Retransmission Exception . . . . . . . . . . . . . . 4 59 3.3.2. Non-Participation . . . . . . . . . . . . . . . . . . 4 60 3.4. Closure of Conversation . . . . . . . . . . . . . . . . . 4 61 3.4.1. Public Conversations and Self-Subscription . . . . . 4 62 3.5. Management and Visibility of Participant Clients and 63 Devices . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 4.1. Participant . . . . . . . . . . . . . . . . . . . . . . . 5 66 4.2. Conversation . . . . . . . . . . . . . . . . . . . . . . 5 67 4.3. Plaintext Content and Sensitive Metadata (PCASM) . . . . 5 68 4.3.1. Content PCASM . . . . . . . . . . . . . . . . . . . . 5 69 4.3.2. Size PCASM . . . . . . . . . . . . . . . . . . . . . 5 70 4.3.3. Descriptive PCASM . . . . . . . . . . . . . . . . . . 6 71 4.3.4. Conversation Metadata (OPTIONAL) . . . . . . . . . . 6 72 4.3.5. Non-PCASM . . . . . . . . . . . . . . . . . . . . . . 6 73 4.4. Backdoor . . . . . . . . . . . . . . . . . . . . . . . . 7 74 4.4.1. Why call this a "backdoor"? . . . . . . . . . . . . . 7 75 5. Scope of a Participant in E2ESM . . . . . . . . . . . . . . . 8 76 6. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 8 77 7. See Also . . . . . . . . . . . . . . . . . . . . . . . . . . 9 78 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 79 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 80 10. Informative References . . . . . . . . . . . . . . . . . . . 9 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 83 1. Introduction 85 End-to-End Secure Messaging (E2ESM) is a mechanism which offers a 86 digital analogue of "closed distribution lists" for sharing message 87 content amongst a set of participants, where all participants are 88 visible to each other and where non-participants are excluded from 89 access to message content. 91 In client-server network models it is common to implement E2ESM by 92 means of encryption, in order to obscure content at rest upon a 93 central server. So therefore E2ESM is often narrowly regarded in 94 terms of "end-to-end encryption". 96 Other architectural approaches exist - for instance [RicochetRefresh] 97 which implements closed distribution by using secure point-to-point 98 [RFC7686] networking to literally restrict the distribution of 99 plaintext content to relevant participants. 101 Therefore we describe E2ESM in terms of functional behaviours of the 102 software rather than in terms of implementation goals and 103 technologies. 105 1.1. Comments 107 Comments are solicited and should be addressed to the working group's 108 mailing list TODO and/or the author(s). 110 1.2. Notational Conventions 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 114 "OPTIONAL" in this document are to be interpreted as described in BCP 115 14 [RFC2119] [RFC8174] when, and only when, they appear in all 116 capitals, as shown here. 118 2. Requirements for an End-to-End Secure Messenger 120 Software which functions as an End-to-End Secure Messenger MUST 121 satisfy the following principles, and MUST satisfy these principles 122 in respect of the provided definitions for all forms of communication 123 and data-sharing that the software offers. 125 Any software that does not satisfy these requirements is not an End- 126 to-End Secure Messenger, and it does not implement End-to-End Secure 127 Messaging, nor does it implement End-to-End Encrypted Messaging. 129 3. Principles 131 For a series of one or more "messages" each which are composed of 132 "plaintext content and sensitive metadata" (PCASM) and which 133 constitute a "conversation" amongst a set of "participants", to 134 provide E2ESM will require: 136 3.1. Equality of Participation 138 All participants MUST be peers who MUST have equal access to any 139 given message's PCASM. 141 3.2. Transparency of Participation 143 The existence of all current conversation participants MUST be 144 visible at the current time to all current conversation participants. 146 3.3. Integrity of Participation 148 Excusing the "retransmission exception", PCASM of any given message 149 MUST only be available to the fixed set of conversation participants 150 from whom, to whom, and at the time when it was sent. 152 3.3.1. Retransmission Exception 154 If a participant that can access an "original" message intentionally 155 "retransmits" (e.g. quotes, forwards) that message to create a new 156 message within the E2ESM software, then the original message's PCASM 157 MAY become available to a new, additional, and possibly different set 158 of conversation participants, via that new message. 160 3.3.2. Non-Participation 162 It follows that for any given message, all entities that exist 163 outside of the above-defined sets of participants will be "non- 164 participants" in respect of that message. 166 3.4. Closure of Conversation 168 The set of participants in a conversation SHALL NOT be increased 169 except by the intentional action of one or more existing 170 participants. 172 3.4.1. Public Conversations and Self-Subscription 174 Existing participants MAY publicly share links, data, or other 175 mechanisms to enable non-participant entities to subscribe themselves 176 as conversation participants. This MAY be considered legitimate 177 "intentional action" to increase the set of participants in the 178 group. 180 3.5. Management and Visibility of Participant Clients and Devices 182 E2ESM software MUST provide each participant entity with means to 183 review or revoke access for clients or devices that can access future 184 PCASM. 186 E2ESM software MUST provide each participant entity with 187 notifications and/or complete logs of changes to the set of clients 188 or devices that can or could access message PCASM. 190 4. Definitions 192 These principles MUST be measured with respect to the following 193 definitions: 195 4.1. Participant 197 A participant is any entity - human, machine, software bot, 198 conversation archiver, or other, that is bounded by the extent of 199 that entity's [TrustedComputingBase]. 201 4.2. Conversation 203 A conversation is a sequence of one or more messages over a period of 204 time amongst a constant or evolving set of participants. 206 4.3. Plaintext Content and Sensitive Metadata (PCASM) 208 The PCASM of a message is defined as any of: 210 4.3.1. Content PCASM 212 Content PCASM is any data that can offer better than 50-50 certainty 213 regarding the value of any given bit of the plaintext message 214 content. ("content") 216 Content PCASM would include, non-exclusively: 218 1. The content is "Hello, world." 220 2. The content starts with the word "Hello" 222 3. The top bit of the first byte of the content in ASCII encoding, 223 is zero 225 4. The MD5 hash of the content is 080aef839b95facf73ec599375e92d47 227 5. The Salted-MD5 Hash of the content is : ... 229 4.3.2. Size PCASM 231 For block encryption of content, Size PCASM is the unpadded size of 232 the content. 234 For stream encryption of content, Size PCASM is currently undefined. 236 For transport encryption of content, precise Size PCASM SHOULD NOT be 237 observable. 239 4.3.3. Descriptive PCASM 241 Descriptive PCASM is data that describes the "content". 243 Descriptive PCASM would include, non-exclusively: 245 1. The content contains the substring "ello" 247 2. The content does not contain the word "Goodbye" 249 3. The content contains a substring from amongst the following set: 250 ... 252 4. The content does not contain a substring from amongst the 253 following set: ... 255 5. The hash of the content exists amongst the following set of 256 hashes: ... 258 6. The hash of the content does not exist amongst the following set 259 of hashes: ... 261 7. The content was matched by a machine-learning classifier with the 262 following training set: ... 264 4.3.4. Conversation Metadata (OPTIONAL) 266 Whether per-conversation "group" metadata, such as "group titles", 267 "group topics", "group icons", or "group participant lists" 268 constitute PCASM, is an OPTIONAL choice for the E2ESM software, but 269 that choice MUST be made apparent to participants. 271 4.3.5. Non-PCASM 273 Information which would not be PCASM would include, non-exclusively: 275 1. The content is sent from Alice 277 2. The content is sent to Bob 279 3. The content is between 1 and 16 bytes long 281 4. The content was sent at the following date and time: ... 283 5. The content was sent from the following IP address: ... 285 6. The content was sent from the following geolocation: ... 287 7. The content was composed using the following platform: ... 289 4.4. Backdoor 291 A "backdoor" is any intentional or unintentional mechanism, in 292 respect of a given message and that message's set of participants, 293 where some PCASM of that message MAY become available to a non- 294 participant without the intentional action of a participant. 296 4.4.1. Why call this a "backdoor"? 298 In software engineering there is a perpetual tension between the 299 concepts of "feature" versus "bug" - and occasionally "misfeature" 300 versus "misbug". These tensions arise from the problem of [DualUse] 301 - that it is not feasible to firmly and completely ascribe 302 "intention" to any hardware or software mechanism. 304 The information security community have experienced a historical 305 spectrum of mechanisms which have assisted non-participant access to 306 PCASM. These have variously been named as "export-grade key 307 restrictions" (TLS, then Logjam), "side channel attacks" (Spectre and 308 Meltdown), "law enforcement access fields" (Clipper), and "key 309 escrow" (Crypto Wars). 311 All of these terms combine an "access facilitation mechanism" with an 312 "intention or opportunity" - and for all of them an access 313 facilitation mechanism is first REQUIRED. 315 An access facilitation mechanism is a "door", and is inherently 316 [DualUse]. Because the goal of E2ESM is to limit access to PCASM 317 exclusively to a defined set of participants, then the intended means 318 of access is clearly the "front door"; and any other access mechanism 319 is a "back door". 321 If the term "back door" is considered innately pejorative, 322 alternative, uncertain constructions such as "illegitimate access 323 feature", "potentially intentional data-access weakness", "legally- 324 obligated exceptional access mechanism", or any other phrase, all 325 MUST combine both notions of an access mechanism (e.g. "door") and a 326 definite or suspected intention (e.g. "legal obligation"). 328 So the phrase "back door" is brief, clear, and widely understood to 329 mean "a secondary means of access". In the above definition we 330 already allow for the term to be prefixed with "intentional" or 331 "unintentional". 333 Thus it seems appropriate to use this term in this context, not least 334 because it is also not far removed from the similar and established 335 term "side channel". 337 5. Scope of a Participant in E2ESM 339 The term "participant" in this document exists to supercede the more 340 vague notion of "end" in the phrase "end-to-end". 342 Participants are defined in terms of an entity's 343 [TrustedComputingBase] to acknowledge that an entity MAY legitimately 344 store, forward, or access messages by means that are outside of the 345 E2ESM software. 347 For example: if a participant accesses their E2ESM software via 348 remote desktop software, and their RDP session is hijacked by a third 349 party; of if they back-up their messages in cleartext to cloud 350 storage leading somehow to data exfiltration, neither of these would 351 be a failure of E2ESM. This would instead be a failure of the 352 participant's [TrustedComputingBase]. 354 6. Rationale 356 Consider FooBook, a hypothetical example company which provides 357 messaging services for conversations between entities who use it. 359 For each conversation FooBook MUST decide whether to represent itself 360 as a conversation participant or as a non-participant. (Transparency 361 of Participation) 363 If FooBook decides to represent itself as a non-participant, then it 364 MUST NOT have any access to PCASM. (Integrity of Participation / 365 Non-Participation) 367 If FooBook decides to represent itself as a participant, then it MUST 368 NOT have privileged access to PCASM, for instance via direct database 369 access, but it MAY have "normal" access to PCASM of conversations 370 where it is a participant. (Integrity of Participation, Equality of 371 Participation) 373 FooBook MAY retain means to eject reported abusive participants from 374 a conversation. (Decrease in Closure of Participation) 376 FooBook MUST NOT retain means to forcibly insert new participants 377 into a conversation. For clarity: this specification does not 378 recognise any notion of "atomic" exchange of one particpant with 379 another, treating it as an ejection, followed by an "illegitimate" 380 insertion. (Increase in Closure of Participation) 381 FooBook MUST enable the user to observe and manage the complete state 382 of their [TrustedComputingBase] with respect to their FooBook 383 messaging services. (Management and Visibility) 385 FooBook MAY treat conversation metadata as PCASM, but it MUST 386 communicate to participants whether it does, or does not. 388 7. See Also 390 A different approach to defining (specifically) end-to-end encryption 391 is discussed in [I-D.knodel-e2ee-definition]. 393 8. IANA Considerations 395 This document has no IANA actions. 397 9. Security Considerations 399 This document is entirely composed of security considerations. 401 10. Informative References 403 [DualUse] Wikipedia, "Dual-use technology", 2021, 404 . 406 [I-D.knodel-e2ee-definition] 407 Knodel, M., Baker, F., Kolkman, O., Celi, S., and G. 408 Grover, "Definition of End-to-end Encryption", Work in 409 Progress, Internet-Draft, draft-knodel-e2ee-definition-00, 410 22 February 2021, . 413 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 414 Requirement Levels", BCP 14, RFC 2119, 415 DOI 10.17487/RFC2119, March 1997, 416 . 418 [RFC7686] Appelbaum, J. and A. Muffett, "The ".onion" Special-Use 419 Domain Name", RFC 7686, DOI 10.17487/RFC7686, October 420 2015, . 422 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 423 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 424 May 2017, . 426 [RicochetRefresh] 427 BlueprintForFreeSpeech, "Ricochet Refresh", 2021, 428 . 430 [TrustedComputingBase] 431 Wikipedia, "Trusted Computing Base", 2021, 432 . 434 Author's Address 436 Alec Muffett 437 Security Researcher 439 Email: alec.muffett@gmail.com