idnits 2.17.1 draft-knodel-e2ee-definition-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: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. 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 March 2022) is 780 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 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: 8 September 2022 6 O. Kolkman 7 ISOC 8 S. Celi 9 Cloudflare 10 G. Grover 11 Centre for Internet and Society 12 7 March 2022 14 Definition of End-to-end Encryption 15 draft-knodel-e2ee-definition-03 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 8 September 2022. 44 Copyright Notice 46 Copyright (c) 2022 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 (https://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. Code Components 54 extracted from this document must include Revised BSD License text as 55 described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Revised BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Formal definition of end-to-end encryption . . . . . . . . . 3 62 2.1. End point . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2.2. End-to-end principle . . . . . . . . . . . . . . . . . . 4 64 2.3. Encryption . . . . . . . . . . . . . . . . . . . . . . . 6 65 2.4. Succinct definition of end-to-end security . . . . . . . 7 66 3. End-to-end encrypted systems design . . . . . . . . . . . . . 7 67 3.1. Features . . . . . . . . . . . . . . . . . . . . . . . . 7 68 3.1.1. Necessary features . . . . . . . . . . . . . . . . . 8 69 3.1.2. Optional/desirable features . . . . . . . . . . . . . 8 70 3.2. Challenges . . . . . . . . . . . . . . . . . . . . . . . 9 71 4. End-user expectations . . . . . . . . . . . . . . . . . . . . 10 72 4.1. A conversation is confidential . . . . . . . . . . . . . 11 73 4.2. Providers are trustworthy . . . . . . . . . . . . . . . . 11 74 4.3. Access by a third-party is impossible . . . . . . . . . . 11 75 4.4. Pattern inference is minimised . . . . . . . . . . . . . 12 76 4.5. The E2EE system is not compromised . . . . . . . . . . . 12 77 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 81 9. Informative References . . . . . . . . . . . . . . . . . . . 13 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 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 and what 106 defines an end, according to the IETF because of its importance to 107 internet protocols; and encryption, an application of cryptography 108 and the primary means employed by the IETF to secure internet 109 protocols. In the tradition of cryptography it's also possible to 110 achieve a succinct definition of end-to-end encrypted security. 112 2.1. End point 114 Intuitively, an "end" either sends messages or receives them, usually 115 both; other systems on the path are just that - other systems. 117 It is, however, not trivial to establish the definition of an end 118 point in isolation, because its existence inherently depends on at 119 least one other entity in a communications system. That is why we 120 will now move directly into an analysis of the end-to-end principle, 121 which introduces nuance, described in the following sub-section. 123 However despite the nuance for engineers, it is now widely accepted 124 that the communication system itself begins and ends with the user 125 [RFC8890]. We imagine people (through an application's user 126 interface, or user agent) as components in a subsystem's design. An 127 important exception to this in E2EE systems might be the use of 128 public key infrastructure where a third party is often used in the 129 authentication phase to enhance the larger system's trust model. 130 Responsible use of of public key infrastructure is required in such 131 cases, such that the E2EE system does not admit third parties under 132 the user's identity. 134 We cannot equate user agent and user, yet we also cannot fully 135 separate them. As user-agent computing becomes more complex and 136 often more proprietary, the user agent becomes less of an "advocate" 137 for the best interests of the user. This is why we focus in a later 138 section on the E2EE system being able to fulfill user expectations. 140 2.2. End-to-end principle 142 We need first to answer "What constitutes an end?", which is an 143 important question in any review of the End-to-End Principle 144 [RFC3724]. However the notion of an end point is more fully defined 145 within the principle of end-to-end communications. 147 In 1984 the "end-to-end argument" was introduced [saltzer] as a 148 design principle that helps guide placement of functions among the 149 modules of a distributed computer system. It suggests that functions 150 placed at low levels of a system may be redundant or of little value 151 when compared with the cost of providing them at that low level. It 152 is used to design around questions about which parts of the system 153 should make which decisions, and as such the identity of the actual 154 "speaker" or "end" may be less obvious than it appears. The 155 communication described by Saltzer is between communicating 156 processes, which may or may not be on the same physical machine, and 157 may be implemented in various ways. For example, a BGP speaker is 158 often implemented as a process that manages the Routing Information 159 Base (RIB) and communicates with other BGP speakers using an 160 operating system service that implements TCP. The RIB manager might 161 find itself searching the RIB for prefixes that should be advertised 162 to a peer, and performing "writes" to TCP for each one. TCP in this 163 context often implements a variant of the algorithm described in RFC 164 868 (the "Nagle algorithm"), which accumulates writes in a buffer 165 until there is no data in flight between the communicants, and then 166 sends it - which might happen several times during a single search by 167 the RIB manager. In that sense, the RIB manager might be thought of 168 as the "end", because it decides what should be communicated, or TCP 169 might be the "end", because it actually sends the TCP Segment, 170 detects errors if they occur, retransmits it if necessary, and 171 ultimately decides that the segment has been successfully 172 transferred. 174 Another important question is "what statement exactly summarizes the 175 end-to-end principle?". Saltzer answered this in two ways, the first 176 of which is that the service implementing the transaction is most 177 correct if it implements the intent of the application that sent it, 178 which would be to move the message toward the destination address in 179 the relevant IP header. Salzer's more thorough treatment, however, 180 deals with end cases that come up in implementation: "Examples 181 discussed in the paper", according to the abstract, "include bit 182 error recovery, security using encryption, duplicate message 183 suppression, recovery from system crashes, and delivery 184 acknowledgement." It also notes that there is occasionally a 185 rationale for ignoring the end-to-end arguments for the purposes of 186 optimization. There may be other user expectations or design 187 features, some explained below, which need to be balanced with the 188 end-to-end argument. 190 More concisely, suppose that an end user is the end identity. An 191 E2EE system may run between potential end points at different network 192 layers within the end identity's possession. These end points may 193 then be considered acceptable sub-identities provided that no path 194 between the end identity and sub-identity is accessible by any third 195 party. There are quite a number of examples of common situations 196 where tunnels are used and this does not apply. For instance, the 197 examples below all provide encryption by which data is turned into 198 clear text in locations that are not under control of the end user: 200 * The common VPNS business model whereby a TLS or an IPsec tunnel 201 terminates at the service provider's server and is subsequently 202 forwarded to its destination elsewhere in unencrypted form; 204 * Email transport whereby an unencrypted message is traverses from 205 sending mail user agent, between various mail transfer agents, and 206 finally to the a receiving mail user agent, all over TLS protected 207 connections; 209 * The encrypted connection of last mile connections such as those in 210 4G LTE; 212 This definition of end points accounts for potentially several 213 devices owned by a user, and various application-specific forwarding 214 or delivery options among them. It also accounts for E2EE systems 215 running at different network layers. Regardless of the sub- 216 identities allowed, the definition is contingent on that all end sub- 217 identities are under the end identity's control and no third party 218 (or their sub-identities, e.g. system components under third-party 219 control) can access the end sub-identities nor links between the sub- 220 identity and end identity. This creates a tree hierarchy with the 221 end user as the root at the top, and all potential end points being 222 under their direct control, without third party access. As an 223 example, decryption at organizational network router before message 224 forwarding (encrypted or unencrypted) to the end identity does not 225 constitute E2EE. However, E2EE to a user's personal device and 226 subsequent E2EE message forwarding to another one of the user's 227 personal devices (without access available to any third party at any 228 link or on device) maintains E2EE data possession for the user. 230 2.3. Encryption 232 From draft-dkg-hrpc-glossary-00, encryption is fundamental to the 233 end-to-end principle. "End-to-End : The principal of extending 234 characteristics of a protocol or system as far as possible within the 235 system. For example, end-to-end instant message encryption would 236 conceal communication content from one user's instant messaging 237 application through any intermediate devices and servers all the way 238 to the recipient's instant messaging application. If the message was 239 decrypted at any intermediate point-for example at a service 240 provider-then the property of end-to-end encryption would not be 241 present."[dkg] Note that this only talks about the contents of the 242 communication and not the metadata generated from it. 244 The way to achieve a truly end-to-end communications system is indeed 245 to encrypt the content of the data exchanged between the endpoints, 246 e.g. sender(s) and receiver(s). The more common end-to-end technique 247 for encrypting uses a double-ratchet algorithm with an authenticated 248 encryption scheme, present in many modern messenger applications such 249 as those considered in the IETF Messaging Layer Security working 250 group, whose charter is to create a document that satisfies the need 251 for several Internet applications for group key establishment and 252 message protection protocols [mls]. OpenPGP, mostly used for email, 253 uses a different technique to achieve encryption. It is also 254 chartered in the IETF to create a specification that covers object 255 encryption, object signing, and identity certification [openpgp]. 256 Both protocols rely on the use of asymmetric and symmetric 257 encryption, and exchange public keys with amongst end points. 259 There are dozens of documents in the RFC Series that fundamentally 260 and technically define encryption schemes. Perhaps interesting work 261 to be done would be to survey all existing documents of this kind to 262 define, in aggregate, their common features. The point is, the IETF 263 has clear mandate and demonstrated expertise in defining the 264 specifics of encrypted communications of the internet. 266 While encryption is fundamental to the end-to-end principle, it does 267 not stand alone. As in the history of all security, authentication 268 and data integrity properties are also linked, and contributed to the 269 end-to-end nature of E2EE. Permission of data manipulation or 270 pseudo-identities for third parties to allow access under the user's 271 identity are against the intention of E2EE. Thus, end point 272 authenticity must be established as (sub-)identities of the end user, 273 and end-to-end integrity must also be maintained by the system. 274 There is considerable system design flexibility available in entity 275 authentication mechanisms and data authentication that still meet 276 this requirement. 278 2.4. Succinct definition of end-to-end security 280 A succinct definition for end-to-end security can describe the 281 security of the system by the probability of an adversary's success 282 in breaking the system. Example snippet: 284 The adversary successfully subverts an end-to-end encrypted system if 285 it can succeed in either of the following: 1) the adversary can 286 produce the participant's local state (meaning the adversary has 287 learned the contents of participant's messages), or 2) the states of 288 conversation participants do not match (meaning that the adversary 289 has influenced their communication in some way). To prevent the 290 adversary from trivially winning, we do not allow the adversary to 291 compromise the participants' local state. 293 We can say that a system is end-to-end secure if the adversary has 294 negligible probability of success in either of these two scenarios 295 [komlo]. 297 3. End-to-end encrypted systems design 299 When looking at E2EE systems from a design perspective, the first 300 consideration is the list of fundamental features that distinguish an 301 E2EE system from one that does not employ E2EE. Secondly one must 302 consider the direction of travel for improving the features of E2EE 303 systems. In other words, what challenges are the designers, 304 developers and implementers of E2EE systems facing? 306 The features and challenges listed below are framed holistically 307 rather than from the perspective of their design, development, 308 implementation or use. 310 3.1. Features 312 Defining a technology can also be done by inspecting what it does, or 313 is meant to do, in the form of features. The features of end-to-end 314 encryption from an implementation perspective can be inspected across 315 several important categories: 1) the necessary features of E2EE of 316 authenticity, confidentiality, and integrity, whereas features of 2) 317 availability, deniability, forward secrecy, and post-compromise 318 security are enhancements to E2EE systems. 320 3.1.1. Necessary features 322 Authenticity A system provides message authenticity if the recipient 323 and sender agree on each other's identities and the contents of 324 their communications. 326 Confidentiality A system provides message confidentiality if only 327 the sender and intended recipient(s) can read the message 328 plaintext, i.e. messages are encrypted by the sender such that 329 only the intended recipient(s) can decrypt them. 331 Integrity A system provides message integrity when it guarantees 332 that messages that have been modified in transit can be detected 333 reliably, i.e. a recipient is assured that a message cannot be 334 undetectably modified in any way. 336 3.1.2. Optional/desirable features 338 Availability A system provides high availability if the user is able 339 to get to the message when they so desire and potentially from 340 more than one device, i.e. a message arrives to a recipient even 341 if they have been offline for a long time. 343 Deniability Deniability ensures that anyone with a record of the 344 transcript, including message recipients, cannot cryptographically 345 prove to others that a particular participant of a communication 346 authored the message. As demonstrated by the Signal and OTR 347 protocols, this optional property must exist in conjunction with 348 the necessary property of message authenticity, i.e. participants 349 in a communication must be assured that they are communicating 350 with the intended parties but this assurance cannot be proof to 351 any other parties. 353 Forward secrecy Forward secrecy is a security property that prevents 354 attackers from decrypting encrypted data they have previously 355 captured over a communication channel before the time of 356 compromise, even if they have compromised one of the endpoints. 357 Forward secrecy is usually achieved by updating the encryption/ 358 decryption keys, and older ones are deleted periodically. 360 Post-compromise security Post-compromise security is a security 361 property that seeks to guarantee a way to recover from an end- 362 point compromise (and consequently that communication sent post- 363 compromise is protected with the same security properties that 364 existed before the compromise). It is usually achieved by adding 365 ephemeral key exchanges to the derivation of encryption/decryption 366 keys. 368 Metadata obfuscation Steps should be taken to minimize metadata such 369 as user obfuscating IP addresses, reducing non-routing metadata, 370 and avoiding extraneous message headers can enhance the 371 confidentiality and security features of E2EE systems. 373 3.2. Challenges 375 Earlier we defined end-to-end encryption using formal definitions 376 assumed by internet protocol implementations. Also because "the IETF 377 is a place for state-of-the-art producing high quality, relevant 378 technical documents that influence the way people design, use, and 379 manage the Internet" we can be confident that current deployments of 380 end-to-end encrypted technologies in the IETF indicate the cutting 381 edge of their developments, yet another way to define what is, or 382 ideally should be, how a technology is defined. 384 Below is an exhaustive, yet vaguely summarised, list of the 385 challenges currently faced by protocol designers of end-to-end 386 encrypted systems. In other words, in order to realise the goals of 387 end-to-end encrypted systems, both for users and implementers (see 388 previous section), these problems must be tackled. Problems that 389 fall outside of this list are likely 1) unnecessary feature requests 390 that negligibly, or do nothing to, achieve the aims of end-to-end 391 encrypted systems or are 2) in some way antithetical to the goals of 392 end-to-end encrypted systems. 394 Public key verification is very difficult for users to manage. 395 Authentication of the two ends is required for confidential 396 conversations. Therefore solving the problem of verification of 397 public keys is a major concern for any end-to-end encrypted system 398 design. Some applications bind together the account identity and the 399 key, and leave users to establish a trust relationship between them, 400 assisted by public key fingerprint information. 402 Users want to smoothly switch application use between devices, but 403 this comes at a cost to the security of user data. Thus, there is a 404 problem of availability in end-to-end encrypted systems because the 405 account identity's private key is generated by and stored on the end- 406 user's original device and to move the private key to another device 407 compromises the security of one of the end-points of the system. 409 Existing protocols are vulnerable to meta-data analysis, even though 410 meta-data is often much more sensitive than content. Meta-data is 411 plaintext information that travels across the wire and includes 412 delivery-relevant details that central servers need such as the 413 account identity of end-points, timestamps, message size. Meta-data 414 is difficult to obfuscate efficiently. 416 Users need to communicate in groups, but this presents major problems 417 of scale for end-to-end encryption systems that rely on public key 418 cryptography. 420 The whole of a user's data should remain secure if only one message 421 is compromised. However, for encrypted communication, you must 422 currently choose between forward secrecy or the ability to 423 communicate asynchronously. This presents a problem for application 424 design that uses end-to-end encryption for asynchronous messaging 425 over email, RCS, etc. 427 Users of E2EE systems should be able to communicate with any medium 428 of their choice, from text to large files, however there is often a 429 resource problem because there are no open protocols to allow users 430 to securely share the same resource in an end-to-end encrypted 431 system. Client-side, e.g. end-point, activities like URL unfurling 432 scanning. 434 Usability considerations are sometimes in conflict with security 435 considerations, such as message read status, typing indicators, URL/ 436 link previews. 438 Deployment is notoriously challenging for any software application 439 where maintenance and updates can be particularly disastrous for 440 obsolete cryptographic libraries. 442 4. End-user expectations 444 While the formal definition and properties of an E2EE system relate 445 to communication security, they do not draw from a comprehensive 446 threat model or speak to what users expect from E2EE communication. 447 It is in this context that some E2EE designs and architectures may 448 ultimately run contrary to user expectations of E2EE systems 449 [GEC-EU]. Although some system designs do not directly violate "the 450 math" of encryption algorithms, they do so by implicating and 451 weakening other important aspects of an E2EE _system_. 453 4.1. A conversation is confidential 455 Users talking to one another in an E2EE system should be the only 456 ones that know what they are talking about [RFC7624]. People have 457 the right to data privacy as defined in international human rights 458 law and within the right to free expression and to hold opinions is 459 inferred the right to whisper, whether or not they are using digital 460 communications or walking through a field. 462 4.2. Providers are trustworthy 464 While "trustworthy" can be rigourously defined from an engineering 465 perspective, for the purposes of this document we choose a definition 466 of Trustworthy inspired by an internal workshop by Internet Society 467 staff: 469 Trustworthy A system is completely trustworthy if and only if it is 470 completely resilient, reliable, accountable, and secure in a way 471 that consistently meets users' expectations. The opposite of 472 trustworthy is untrustworthy. 474 This definition is complete in its positive and negative aspects: 475 what it is, e.g. "Worthy of confidence" and what it is not, e.g. in 476 RFC 7258: "behavior that subverts the intent of communicating parties 477 without the agreement of those parties" [RFC7258]. 479 Therefore, a trustworthy end-to-end encrypted communication system is 480 the set of functions needed by two or more parties to communicate 481 among each other in a confidential and authenticated fashion without 482 any third party having access to the content of that communication 483 where the functions that offer the confidentiality and authenticity 484 are trustworthy. 486 4.3. Access by a third-party is impossible 488 No matter the specifics, any methods used to access to the content of 489 the messages by a third party would violate a user's expectations of 490 E2EE messaging. "[T]hese access methods scan message contents on the 491 user's [device]", which are then "scanned for matches against a 492 database of prohibited content before, and sometimes after, the 493 message is sent to the recipient" [GEC-EU]. Third party access also 494 covers cases without scanning - namely, it should not be possible for 495 any third-party end point to access the data regardless of reason. 497 If a method makes private communication, intended to be sent over an 498 encrypted channel between end points, available to parties other than 499 the sender and intended recipient(s), without formally interfering 500 with channel confidentiality, that method violates the understood 501 expectation of that security property. 503 4.4. Pattern inference is minimised 505 Analyses such as traffic fingerprinting or other (encrypted or 506 unencrypted) data analysis techniques should be considered outside 507 the scope of an E2EE system's goals of providing secure 508 communications to end users. 510 Such methods of analyses, outside of or as part of E2EE system 511 design, allow third parties to draw inferences from communication 512 that was intended to be confidential. "By allowing private user data 513 to be scanned via direct access by servers and their providers," the 514 use of these methods should be considered an affront to "the privacy 515 expectations of users of end-to-end encrypted communication systems" 516 [GEC-EU]. 518 Not only should an E2EE system value user data privacy by not 519 enabling pattern inference, it should actively be attempting to solve 520 issues of metadata and traceability (enhanced metadata) through 521 further innovation that stays ahead of advances in these techniques. 523 4.5. The E2EE system is not compromised 525 RFC 3552 talks about the Internet Threat model such as the assumption 526 that the user can expect any communications systems, but perhaps 527 especially E2EE systems, to not be intentionally compromised 528 [RFC3552]. Intentional compromises of E2EE systems are often 529 referred to as "backdoors" but are often presented as additional 530 design features under terms like "key escrow." Users of E2EE systems 531 would not expect a front, back or side door entrance into their 532 confidential conversations and would expect a provider to actively 533 resist - technically and legally - compromise through these means. 535 5. Conclusions 537 From messaging to video conferencing, there are many competing 538 features in an E2EE system that is secure and usable. The most well 539 designed system cannot meet the expectations of every user, nor does 540 an ideal system exist from any dimension. E2EE is a technology that 541 is constantly improving to achieve the ideal as defined in this 542 document. 544 Features and functionalities of E2EE systems should be developed and 545 improved in service of end user expectations for privacy preserving 546 communications. 548 6. Acknowledgements 550 Fred Baker, Stephen Farrell, Richard Barnes, Olaf Kolkman all 551 contributed to the early strategic thinking of this document and 552 whether it would be useful to the IETF community. 554 The folks at Riseup and the LEAP Encryption Access Project have 555 articulated brilliantly the hardest parts of end-to-end encryption 556 systems that serve the end users' right to whisper. 558 Ryan Polk at the Internet Society has energy to spare when it comes 559 to organising meaningful contributions, like this one, for the 560 technical advisors of the Global Encryption Coalition. 562 Adrian Farrel, are acknowleded for their review, comments, or 563 questions that lead to improvement of this document. 565 7. Security Considerations 567 This document does not specify new protocols and therefore does not 568 bring up technical security considerations. 570 Because some policy decicions may affect the security of the 571 Internet, a clear and shared definition of end to end encrypted 572 communication is important in policy related discussions. This 573 document aims to provide that clarity. 575 8. IANA Considerations 577 This document has no actions for IANA. 579 9. Informative References 581 [dkg] Gillmor, D., "Human Rights Protocol Considerations 582 Glossary", 2015, 583 . 585 [GEC-EU] Global Encryption Coaliation, ., "Breaking encryption 586 myths: What the European Commission’s leaked report got 587 wrong about online security", 2020, 588 . 591 [komlo] Chelsea Komlo, ., "Defining end-to-end security", 2021, 592 . 595 [mls] IETF, ., "Messaging Layer Security", 2018, 596 . 598 [openpgp] IETF, ., "Open Specification for Pretty Good Privacy", 599 2020, 600 . 602 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 603 Text on Security Considerations", BCP 72, RFC 3552, 604 DOI 10.17487/RFC3552, July 2003, 605 . 607 [RFC3724] Kempf, J., Ed., Austein, R., Ed., and IAB, "The Rise of 608 the Middle and the Future of End-to-End: Reflections on 609 the Evolution of the Internet Architecture", RFC 3724, 610 DOI 10.17487/RFC3724, March 2004, 611 . 613 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 614 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 615 2014, . 617 [RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., 618 Trammell, B., Huitema, C., and D. Borkmann, 619 "Confidentiality in the Face of Pervasive Surveillance: A 620 Threat Model and Problem Statement", RFC 7624, 621 DOI 10.17487/RFC7624, August 2015, 622 . 624 [RFC8890] Nottingham, M., "The Internet is for End Users", RFC 8890, 625 DOI 10.17487/RFC8890, August 2020, 626 . 628 [saltzer] Saltzer, et al, J.H., "End-to-end arguments in system 629 design", 1984, 630 . 633 Authors' Addresses 635 Mallory Knodel 636 CDT 637 Email: mknodel@cdt.org 638 Fred Baker 639 Email: fredbaker.IETF@gmail.com 641 Olaf Kolkman 642 ISOC 643 Email: kolkman@isoc.org 645 Sofía Celi 646 Cloudflare 647 Email: cherenkov@riseup.net 649 Gurshabad Grover 650 Centre for Internet and Society 651 Email: gurshabad@cis-india.org