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