idnits 2.17.1 draft-knodel-e2ee-definition-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 : ---------------------------------------------------------------------------- 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 (May 07, 2021) is 1085 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 mls M. Knodel 3 Internet-Draft CDT 4 Intended status: Informational F. Baker 5 Expires: November 8, 2021 6 O. Kolkman 7 ISOC 8 S. Celi 9 Cloudflare 10 G. Grover 11 Centre for Internet and Society 12 May 07, 2021 14 Definition of End-to-end Encryption 15 draft-knodel-e2ee-definition-01 17 Abstract 19 End-to-end encryption (E2EE) is an application of cryptography in 20 communications systems between endpoints. E2EE systems are unique in 21 providing features of confidentiality, integrity and authenticity for 22 users. Improvements to E2EE strive to maximise the system's security 23 while balancing usability and availability. Users of E2EE 24 communications expect trustworthy providers of secure implementations 25 to respect and protect their right to whisper. 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 November 8, 2021. 44 Copyright Notice 46 Copyright (c) 2021 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. Formal definition of end-to-end encryption . . . . . . . . . 3 63 2.1. End point . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2.2. End-to-end principle . . . . . . . . . . . . . . . . . . 3 65 2.3. Encryption . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. End-to-end encrypted systems design . . . . . . . . . . . . . 5 67 3.1. Features . . . . . . . . . . . . . . . . . . . . . . . . 5 68 3.1.1. Necessary features . . . . . . . . . . . . . . . . . 6 69 3.1.2. Optional/desirable features . . . . . . . . . . . . . 6 70 3.2. Challenges . . . . . . . . . . . . . . . . . . . . . . . 7 71 4. End-user expectations . . . . . . . . . . . . . . . . . . . . 8 72 4.1. A conversation is confidential . . . . . . . . . . . . . 8 73 4.2. Providers are trustworthy . . . . . . . . . . . . . . . . 9 74 4.3. Access by a third-party is impossible . . . . . . . . . . 9 75 4.4. Pattern inference is minimised . . . . . . . . . . . . . 9 76 4.5. The e2ee system is not compromised . . . . . . . . . . . 10 77 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 81 9. Informative References . . . . . . . . . . . . . . . . . . . 11 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 84 1. Introduction 86 This document defines end-to-end encryption (E2EE) using three 87 different dimensions that together comprise a full definition of 88 E2EE, which can be applied in a variety of contexts. 90 The first is a formal definition that draws on the basic 91 understanding of end points and cryptography. The second looks at 92 E2EE systems from a design perspective, both its fundamental features 93 and the direction of travel towards improving those features. Lastly 94 we consider the expectations of the user of E2EE systems. 96 These dimensions taken as a whole comprise a generally comprehensible 97 picture of consensus at the IETF as to what is end-to-end encryption, 98 irrespective of application, from messaging to video conferencing, 99 and between any number of end points. 101 2. Formal definition of end-to-end encryption 103 An end-to-end encrypted communications system, irrespective of the 104 content or the specific methods employed, relies on two important and 105 rigorous technical concepts: The end-to-end principle, defined in the 106 IETF because of its importance to internet protocols; and encryption, 107 an application of cryptography and the primary means employed by the 108 IETF to secure internet protocols. 110 2.1. End point 112 Intuitively, an "end" either sends messages or receives them, usually 113 both; other systems on the path are just that - other systems. 115 It is, however, not trivial to establish the definition of an end 116 point in isolation, because its existence inherentely depends on at 117 least one other entity in a communications system. That is why we 118 will now move directly into an anlaysis of the end-to-end principle, 119 which introduces nuance, described in the following sub-section. 121 However despite the nuance for engineers, it is now widely accepted 122 that the communication system itself begins and ends with the user 123 [RFC8890]. We imagine people (through an application's user 124 interface, or user agent) as components in a subsystem's design. An 125 important exception to this in E2EE systems might be the use of 126 public key infrastructure where a third party is often used in the 127 authentication phase to enhance the larger system's trust model. 129 We cannot equate user agent and user, yet we also cannot fully 130 separate them. As user-agent computing becomes more complex and 131 often more proprietary, the user agent less of an "advocate" for the 132 best interests of the user. This is why we focus in a later section 133 on the e2ee system being able to fulfil user expectations. 135 2.2. End-to-end principle 137 We needed first to answer "what constitutes an end?", which is an 138 important question in any review of the End-to-End Principle 139 [RFC3724]. However the notion of an end point is more fully defined 140 within the principle of end-to-end communications. 142 In 1984 the "end-to-end argument" was introduced [saltzer] as a 143 design principle that helps guide placement of functions among the 144 modules of a distributed computer system. It suggests that functions 145 placed at low levels of a system may be redundant or of little value 146 when compared with the cost of providing them at that low level. 147 It's used to design around questions about which parts of the system 148 should make which decisions, and as such the identity of the actual 149 "speaker" or "end" may be less obvious than it appears. The 150 communication described by Saltzer is between communicating 151 processes, which may or may not be on the same physical machine, and 152 may be implemented in various ways. For example, a BGP speaker is 153 often implemented as a process that manages the Routing Information 154 Base (RIB) and communicates with other BGP speakers using an 155 operating system service that implements TCP. The RIB manager might 156 find itself searching the RIB for prefixes that should be advertised 157 to a peer, and performing "writes" to TCP for each one. TCP in this 158 context often implements a variant of the algorithm described in RFC 159 868 (the "Nagle algorithm"), which accumulates writes in a buffer 160 until there is no data in flight between the communicants, and then 161 sends it - which might happen several times during a single search by 162 the RIB manager. In that sense, the RIB manager might be thought of 163 as the "end", because it decides what should be communicated, or TCP 164 might be the "end", because it actually sends the TCP Segment, 165 detects errors if they occur, retransmits it if necessary, and 166 ultimately decides that the segment has been successfully 167 transferred. 169 Another important question is "what statement exactly summarizes the 170 end-to-end principle?". Saltzer answered this in two ways, the first 171 of which is that the service implementing the transaction is most 172 correct if it implements the intent of the application that sent it, 173 which would be to move the message toward the destination address in 174 the relevant IP header. Salzer's more thorough treatment, however, 175 deals with end cases that come up in implementation: "Examples 176 discussed in the paper", according to the abstract, "include bit 177 error recovery, security using encryption, duplicate message 178 suppression, recovery from system crashes, and delivery 179 acknowledgement." It also notes that there is occasionally a 180 rationale for ignoring the end-to-end arguments for the purposes of 181 optimization. There may be other user expectations or design 182 features, some explained below, which need to be balanced with the 183 end-to-end argument. 185 2.3. Encryption 187 From draft-dkg-hrpc-glossary-00, encryption is fundamental to the 188 end-to-end principle. "End-to-End : The principal of extending 189 characteristics of a protocol or system as far as possible within the 190 system. For example, end-to-end instant message encryption would 191 conceal communication content from one user's instant messaging 192 application through any intermediate devices and servers all the way 193 to the recipient's instant messaging application. If the message was 194 decrypted at any intermediate point-for example at a service 195 provider-then the property of end-to-end encryption would not be 196 present."[dkg] Note that this only talks about the contents of the 197 communication and not the metadata generated from it. 199 The way to achieve a truly end-to-end communications system is indeed 200 to encrypt the content of the data exchanged between the endpoints, 201 eg sender(s) and receiver(s). The more common end-to-end technique 202 for encrypting uses a double-ratchet algorithm with an authenticated 203 encryption scheme, present in many modern messenger applications such 204 as those considered in the IETF Messaging Layer Security working 205 group, whose charter is to create a document that satisfies the need 206 for several Internet applications for group key establishment and 207 message protection protocols.[mls] OpenPGP, mostly used for email, 208 uses a different technique to achieve encryption. It is also 209 chartered in the IETF to create an specification that covers object 210 encryption, object signing, and identity certification.[openpgp] Both 211 protocols rely on the use of asymmetric and symmetric encryption, and 212 have to exchange public keys with amongst end points. 214 There are dozens of documents in the RFC Series that fundamentally 215 and technically define encryption schemes. Perhaps interesting work 216 to be done would be to survey all existing documents of this kind to 217 define, in aggregate, their common features. The point is, the IETF 218 has clear mandate and demonstrated expertise in defining the 219 specifics of encrypted communications of the internet. 221 3. End-to-end encrypted systems design 223 When looking at E2EE systems from a design perspective, the first 224 consideration is the list of fundamental features that distinguish an 225 E2EE system from one that does not employ E2EE. Secondly one must 226 consider the direction of travel for improving the features of E2EE 227 systems. In other words, what challenges are the designers, 228 developers and implementers of E2EE systems facing? 230 The features and challenges listed below are framed holistically 231 rather than from the perspective of their design, development, 232 implementation or use. 234 3.1. Features 236 Defining a technology can also be done by inspecting what it does, or 237 is meant to do, in the form of features. The features of end-to-end 238 encryption from an implementation perspective can be inspected across 239 several important categories: 1) the necessary features of E2EE of 240 authenticity, confidentiality and integrity, whereas features of 2) 241 availability, deniability, forward secrecy and post-compromise 242 security are enhancements to E2EE systems. 244 3.1.1. Necessary features 246 Authenticity A system provides message authenticity if the recipient 247 is certain who sent the message and the sender is certain who 248 received it. 250 Confidentiality A system provides message confidentiality if only 251 the sender and intended recipient(s) can read the message 252 plaintext, i.e. messages are encrypted by the sender such that 253 only the intended recipient(s) can decrypt them. 255 Integrity A system provides message integrity when it guarantees 256 that messages has not been modified in transit, i.e. a recipient 257 is assured that the message they have received is exactly what the 258 sender intented to sent. 260 3.1.2. Optional/desirable features 262 Availability A system provides high availability if the user is able 263 to get to the message when they so desire and potentially from 264 more than one device, i.e. a message arrives to a recipient even 265 if they have been offline for a long time. 267 Deniability Deniability ensures that anyone with a record of the 268 transcript, including message recipients, cannot cryptographically 269 prove to others that a particular participant of a communication 270 authored the message. As demonstrated by the Signal and OTR 271 protocols, this property has to exist in conjunction with message 272 authenticity, i.e. participants in a communication have to be 273 assured that they are communicating with the intended parties but 274 this assurance cannot be proof to any other parties. 276 Forward secrecy Forward secrecy is a security property that prevents 277 attackers from decrypting all encrypted data they have previously 278 captured over a communication channel, even if they have 279 compromised one of the endpoints. Forward secrecy is usually 280 achieved by updating the encryption/decryption keys, and older 281 ones are deleted periodically. 283 Post-compromise security Post-compromise security is a security 284 property that seeks to guarantee a way to recover from an end- 285 point compromise (and consequently that communication sent post- 286 compromise is protected with the same security properties that 287 existed before the compromise). It is usually achieved by adding 288 ephemeral key exchanges to the derivation of encryption/decryption 289 keys. 291 3.2. Challenges 293 Earlier we defined end-to-end encryption using formal definitions 294 assumed by internet protocol implementations. And because "the IETF 295 is a place for state-of-the-art producing high quality, relevant 296 technical documents that influence the way people design, use, and 297 manage the Internet" we can be confident that current deployments of 298 end-to-end encrypted technologies in the IETF indicate the cutting 299 edge of their developments, yet another way to define what is, or 300 ideally should be, how a technology is defined. 302 Below is an exhaustive, yet vaguely summarised, list of the 303 challenges currently faced by protocol designers of end-to-end 304 encrypted systems. In other words, in order to realise the goals of 305 end-to-end encrypted systems, both for users and implementers (see 306 previous section), these problems must be tackled. Problems that 307 fall outside of this list are likely 1) unnecessary feature requests 308 that negligibly, or do nothing to, achieve the aims of end-to-end 309 encrypted systems or 2) in some way antithetical to the goals of end- 310 to-end encrypted systems. 312 Public key verification is very difficult for users to manage. 313 Authentication of the two ends is required for confidential 314 conversations. Therefore solving the problem of verification of 315 public keys is a major concern for any end-to-end encrypted system 316 design. Some applications bind together the account identity and the 317 key, and leaves users to establish a trust relationship between them, 318 assisted by public key fingerprint information. 320 Users want to smoothly switch application use between devices, but 321 this comes at a cost to the security of user data. Thus there is a 322 problem of availability in end-to-end encrypted systems because the 323 account identity's private key is generated by and stored on the end- 324 user's original device and to move the private key to another device 325 compromises the security of one of the end-points of the system. 327 Existing protocols are vulnerable to meta-data analysis, even though 328 meta-data is often much more sensitive than content. Meta-data is 329 plaintext information that travels across the wire and includes 330 delivery-relevant details that central servers need such as the 331 account identity of end-points, timestamps, message size. Meta-data 332 is difficult to obfuscate efficiently. 334 Users need to communicate in groups, but this presents major problems 335 of scale for end-to-end encryption systems that rely on public key 336 cryptography. 338 The whole of a user's data should remain secure if only one message 339 is compromised. However, for encrypted communication, you must 340 currently choose between forward secrecy or the ability to 341 communicate asynchronously. This presents a problem for application 342 design that uses end-to-end encryption for asynchronous messaging 343 over email, RCS, etc. 345 Users of E2EE systems should be able to communicate with any medium 346 of their choice, from plain text to large files, however there is 347 often a resource problem because there are no open protocols to allow 348 users to securely share the same resource in an end-to-end encrypted 349 system. Client-side, eg end-point, activities like URL unfurling 350 scanning. 352 Usability considerations are sometimes in conflict with security 353 considerations, such as message read status, typing indicators, URL/ 354 link previews. 356 Deployment is notoriously challenging for any software application 357 where maintenance and updates can be particularly disastrous for 358 obsolete cryptographic libraries. 360 4. End-user expectations 362 While the formal definition and properties of an E2EE system relate 363 to communication security, they do not draw from a comprehensive 364 threat model or speak to what users expect from E2EE communication. 365 It is in this context that some E2EE designs and architectures may 366 ultimately run contrary to user expectations of E2EE systems. 367 [GEC-EU] Although some system designs do not directly violate "the 368 math" of encryption algorithms, they do so by implicating and 369 weakening other important aspects of an E2EE _system_. 371 4.1. A conversation is confidential 373 Users talking to one another in an E2EE system should be the only 374 ones that know what they are talking about [RFC7624]. People have 375 the right to privacy as defined in international human rights law and 376 within the right to free expression and to hold opinions is inferred 377 the right to whisper, whether or not they are using digital 378 communications or walking through a field. 380 4.2. Providers are trustworthy 382 While trustworth can be rigourously defined from an engineering 383 perspective, for the purposes of this document we choose a definition 384 of Trustworthy inspired by an internal workshop by Internet Society 385 staff: 387 Trustworthy A system is completely trustworthy if and only if it is 388 completely resilient, reliable, accountable, and secure in a way 389 that consistently meets users' expectations. The opposite of 390 trustworthy is untrustworthy. 392 This definition is complete in its positive and negative aspects: 393 what it is, eg "Worthy of confidence" and what it isn't, eg in RFC 394 7258: "behavior that subverts the intent of communicating 395 partieswithout the agreement of those parties." [RFC7258] 397 Therefore, a trustworthy end-to-end encrypted communication system is 398 the set of functions needed by two or more parties to communicate 399 among each other in a confidential and authenticated fashion without 400 any third party having access to the content of that communication 401 where the functions that offer the confidentiallity and authenticity 402 are trustworthy. 404 4.3. Access by a third-party is impossible 406 No matter the specifics, any methods used to access to the content of 407 the messages by a third party would violate a user's expectations of 408 E2EE messaging. "[T]hese access methods scan message contents on the 409 user's [device]", which are then "scanned for matches against a 410 database of prohibited content before, and sometimes after, the 411 message is sent to the recipient." [GEC-EU] 413 If a method makes private communication, intended to be sent over an 414 encrypted channel between end points, available to parties other than 415 the recipient, without formally interfering with channel 416 confidentiality, that method violates the understood expectation of 417 that security property. 419 4.4. Pattern inference is minimised 421 Analyses such as traffic fingerprinting or homomorphic encryption 422 computations should be considred outside the scope of an E2EE 423 system's goals of providing secure communications to end users. 425 Such methods of analyses, outside of or as part of E2EE system 426 design, allows third parties to draw inferences from communication 427 that was intended to be confidential. "By allowing private user data 428 to be scanned via direct access by servers and their providers," the 429 use of these methods should be considered an affront to "the privacy 430 expectations of users of end-to-end encrypted communication systems." 431 [GEC-EU] 433 Not only should an E2EE system value user privacy by not allowing 434 pattern inference, it should actively be attempting to solve issues 435 of metadata and traceability (enhanced metadata) through further 436 innovation that stays ahead of advances in these techniques. 438 4.5. The e2ee system is not compromised 440 RFC 3552 talks about the Internet Threat model such as the assumption 441 that the user can expect any communications systems, but perhaps 442 especially E2EE systems, not being compromised.[RFC3552] Compromises 443 to E2EE systems are often referred to as "backdoors" but are often 444 presented as additional design features like "key escrow." Users of 445 E2EE systems would not expect a front, back or side door entrance 446 into their confidential conversations and would expect a provider to 447 actively resist- technically and legally- compromise through these 448 means. 450 5. Conclusions 452 From messaging to video conferencing, there are many competing 453 features in an E2EE system that is secure and usable. The most well 454 designed system cannot meet the expectations of every user, nor does 455 an ideal system exist from any dimension. E2EE is a technology that 456 is constantly improving to achieve the ideal as defined in this 457 document. 459 Features and functionalities of e2ee systems should be developed and 460 improved in service of end user expectations for privacy preserving 461 communications. 463 6. Acknowledgements 465 Fred Baker, Stephen Farrell, Richard Barnes, Olaf Kolkman all 466 contributed to the early strategic thinking of this document and 467 whether it would be useful to the IETF community. 469 The folks at Riseup and the LEAP Encryption Access Project have 470 articulated brilliantly the hardest parts of end-to-end encryption 471 systems that serve the end users' right to whisper. 473 Ryan Polk at the Internet Society has energy to spare when it comes 474 to organising meaningful contributions, like this one, for the 475 technical advisors of the Global Encryption Coalition. 477 7. Security Considerations 479 As this draft concerns an informational document, there are no 480 security considerations. 482 8. IANA Considerations 484 This document has no actions for IANA. 486 9. Informative References 488 [dkg] Gillmor, D., "Human Rights Protocol Considerations 489 Glossary", 2015, 490 . 492 [GEC-EU] Global Encryption Coaliation, ., "Breaking encryption 493 myths: What the European Commission's leaked report got 494 wrong about online security", 2020, 495 . 498 [mls] IETF, ., "Messaging Layer Security", 2018, 499 . 501 [openpgp] IETF, ., "Open Specification for Pretty Good Privacy", 502 2020, 503 . 505 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 506 Text on Security Considerations", BCP 72, RFC 3552, 507 DOI 10.17487/RFC3552, July 2003, 508 . 510 [RFC3724] Kempf, J., Ed., Austein, R., Ed., and IAB, "The Rise of 511 the Middle and the Future of End-to-End: Reflections on 512 the Evolution of the Internet Architecture", RFC 3724, 513 DOI 10.17487/RFC3724, March 2004, 514 . 516 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 517 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 518 2014, . 520 [RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., 521 Trammell, B., Huitema, C., and D. Borkmann, 522 "Confidentiality in the Face of Pervasive Surveillance: A 523 Threat Model and Problem Statement", RFC 7624, 524 DOI 10.17487/RFC7624, August 2015, 525 . 527 [RFC8890] Nottingham, M., "The Internet is for End Users", RFC 8890, 528 DOI 10.17487/RFC8890, August 2020, 529 . 531 [saltzer] Saltzer, et al, J., "End-to-end arguments in system 532 design", 1984, 533 . 536 Authors' Addresses 538 Mallory Knodel 539 CDT 541 Email: mknodel@cdt.org 543 Fred Baker 545 Email: fredbaker.IETF@gmail.com 547 Olaf Kolkman 548 ISOC 550 Email: kolkman@isoc.org 552 Sofia Celi 553 Cloudflare 555 Email: cherenkov@riseup.net 557 Gurshabad Grover 558 Centre for Internet and Society 560 Email: gurshabad@cis-india.org