idnits 2.17.1 draft-arkko-farrell-arch-model-t-redux-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 3, 2020) is 1270 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'AbuseCases' is defined on line 699, but no explicit reference was found in the text == Unused Reference: 'BgpHijack' is defined on line 721, but no explicit reference was found in the text == Unused Reference: 'CommandAndControl' is defined on line 745, but no explicit reference was found in the text == Unused Reference: 'DeepDive' is defined on line 759, but no explicit reference was found in the text == Unused Reference: 'DoubleKey' is defined on line 765, but no explicit reference was found in the text == Unused Reference: 'GDPRAccess' is defined on line 773, but no explicit reference was found in the text == Unused Reference: 'HijackDet' is defined on line 777, but no explicit reference was found in the text == Unused Reference: 'I-D.iab-protocol-maintenance' is defined on line 818, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-mls-architecture' is defined on line 828, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-rats-eat' is defined on line 839, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-teep-architecture' is defined on line 844, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-teep-protocol' is defined on line 850, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-tls-grease' is defined on line 861, but no explicit reference was found in the text == Unused Reference: 'I-D.mcfadden-smart-endpoint-taxonomy-for-cless' is defined on line 870, but no explicit reference was found in the text == Unused Reference: 'I-D.nottingham-for-the-users' is defined on line 875, but no explicit reference was found in the text == Unused Reference: 'I-D.taddei-smart-cless-introduction' is defined on line 879, but no explicit reference was found in the text == Unused Reference: 'I-D.wood-pearg-website-fingerprinting' is defined on line 890, but no explicit reference was found in the text == Unused Reference: 'Jager2015' is defined on line 895, but no explicit reference was found in the text == Unused Reference: 'LeakyBuckets' is defined on line 910, but no explicit reference was found in the text == Unused Reference: 'Mozilla2019' is defined on line 941, but no explicit reference was found in the text == Unused Reference: 'RFC3935' is defined on line 962, but no explicit reference was found in the text == Unused Reference: 'RFC4655' is defined on line 966, but no explicit reference was found in the text == Unused Reference: 'RFC6454' is defined on line 975, but no explicit reference was found in the text == Unused Reference: 'RFC6480' is defined on line 979, but no explicit reference was found in the text == Unused Reference: 'RFC6749' is defined on line 983, but no explicit reference was found in the text == Unused Reference: 'RFC6819' is defined on line 992, but no explicit reference was found in the text == Unused Reference: 'RFC6962' is defined on line 997, but no explicit reference was found in the text == Unused Reference: 'RFC6973' is defined on line 1001, but no explicit reference was found in the text == Unused Reference: 'RFC7830' is defined on line 1030, but no explicit reference was found in the text == Unused Reference: 'StackEvo' is defined on line 1075, but no explicit reference was found in the text == Unused Reference: 'Sybil' is defined on line 1081, but no explicit reference was found in the text == Unused Reference: 'Toys' is defined on line 1100, but no explicit reference was found in the text == Unused Reference: 'Troll' is defined on line 1112, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-iab-protocol-maintenance-04 == Outdated reference: A later version (-13) exists of draft-ietf-mls-architecture-05 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-32 == Outdated reference: A later version (-25) exists of draft-ietf-rats-eat-04 == Outdated reference: A later version (-19) exists of draft-ietf-teep-architecture-12 == Outdated reference: A later version (-18) exists of draft-ietf-teep-protocol-03 == Outdated reference: A later version (-18) exists of draft-ietf-tls-esni-08 == Outdated reference: A later version (-04) exists of draft-thomson-tmi-00 -- Obsolete informational reference (is this intentional?): RFC 6962 (Obsoleted by RFC 9162) -- Obsolete informational reference (is this intentional?): RFC 7231 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 7540 (Obsoleted by RFC 9113) -- No information found for draft-trammell-whats-an-endpoint - is the name correct? Summary: 0 errors (**), 0 flaws (~~), 42 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Arkko 3 Internet-Draft Ericsson 4 Intended status: Informational S. Farrell 5 Expires: May 7, 2021 Trinity College Dublin 6 November 3, 2020 8 Internet Threat Model Evolution: Background and Principles 9 draft-arkko-farrell-arch-model-t-redux-00 11 Abstract 13 Communications security has been at the center of many security 14 improvements in the Internet. The goal has been to ensure that 15 communications are protected against outside observers and attackers. 17 This memo suggests that the existing RFC 3552 threat model, while 18 important and still valid, is no longer alone sufficient to cater for 19 the pressing security and privacy issues seen on the Internet today. 20 For instance, it is often also necessary to protect against endpoints 21 that are compromised, malicious, or whose interests simply do not 22 align with the interests of users. While such protection is 23 difficult, there are some measures that can be taken and we argue 24 that investigation of these issues is warranted. 26 It is particularly important to ensure that as we continue to develop 27 Internet technology, non-communications security related threats, and 28 privacy issues, are properly understood. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on May 7, 2021. 47 Copyright Notice 49 Copyright (c) 2020 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Attack Landscape . . . . . . . . . . . . . . . . . . . . . . 5 66 2.1. Communications Security Improvements . . . . . . . . . . 5 67 2.2. Beyond Communications Security . . . . . . . . . . . . . 6 68 2.3. Types of Attacks . . . . . . . . . . . . . . . . . . . . 7 69 2.3.1. Misuse of Accidental Vulnerabilities . . . . . . . . 7 70 2.3.2. Misbehaving Applications . . . . . . . . . . . . . . 8 71 2.3.3. Network Infrastructure Attacks . . . . . . . . . . . 8 72 2.3.4. Untrustworthy Devices . . . . . . . . . . . . . . . . 9 73 2.3.5. Tracking . . . . . . . . . . . . . . . . . . . . . . 10 74 3. Principles . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 3.1. Trusting Devices . . . . . . . . . . . . . . . . . . . . 13 76 3.2. Protecting Information . . . . . . . . . . . . . . . . . 13 77 3.3. Tracking . . . . . . . . . . . . . . . . . . . . . . . . 13 78 3.4. Role of End-to-End . . . . . . . . . . . . . . . . . . . 14 79 4. Security Considerations . . . . . . . . . . . . . . . . . . . 15 80 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 81 6. Informative References . . . . . . . . . . . . . . . . . . . 15 82 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 25 83 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 25 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 86 1. Introduction 88 Communications security has been at the center of many security 89 improvements in the Internet. The goal has been to ensure that 90 communications are protected against outside observers and attackers. 91 At the IETF, this approach has been formalized in BCP 72 [RFC3552], 92 which defined the Internet threat model in 2003. 94 The purpose of a threat model is to outline what threats exist in 95 order to assist the protocol designer. But RFC 3552 also ruled some 96 threats to be in scope and of primary interest, and some threats out 97 of scope [RFC3552]: 99 The Internet environment has a fairly well understood threat 100 model. In general, we assume that the end-systems engaging in a 101 protocol exchange have not themselves been compromised. 102 Protecting against an attack when one of the end-systems has been 103 compromised is extraordinarily difficult. It is, however, 104 possible to design protocols which minimize the extent of the 105 damage done under these circumstances. 107 By contrast, we assume that the attacker has nearly complete 108 control of the communications channel over which the end-systems 109 communicate. This means that the attacker can read any PDU 110 (Protocol Data Unit) on the network and undetectably remove, 111 change, or inject forged packets onto the wire. 113 However, the communications-security -only threat model is becoming 114 outdated. Some of the causes for this are: 116 o Success! Advances in protecting most of our communications with 117 strong cryptographic means. This has resulted in much improved 118 communications security, but also highlights the need for 119 addressing other, remaining issues. This is not to say that 120 communications security is not important, it still is: 121 improvements are still needed. Not all communications have been 122 protected, and even out of the already protected communications, 123 not all of their aspects have been fully protected. Fortunately, 124 there are ongoing projects working on improvements. 126 o Adversaries have increased their pressure against other avenues of 127 attack, from supply-channel attacks, to compromising devices to 128 legal coercion of centralized endpoints in conversations. 130 o New adversaries and risks have arisen, e.g., due to creation of 131 large centralized information sources. 133 o While communications-security does seem to be required to protect 134 privacy, more is needed, especially if endpoints choose to act 135 against the interests of their peers or users. 137 In short, attacks are migrating towards the currently easier targets, 138 which no longer necessarily include direct attacks on traffic flows. 139 In addition, trading information about users and ability to influence 140 them has become a common practice for many Internet services, often 141 without users understanding those practices. 143 This memo suggests that the existing threat model, while important 144 and still valid, is no longer alone sufficient to cater for the 145 pressing security and privacy issues on the Internet. For instance, 146 while it continues to be very important to protect Internet 147 communications against outsiders, it is also necessary to protect 148 systems against endpoints that are compromised, malicious, or whose 149 interests simply do not align with the interests of the users. 151 Of course, there are many trade-offs in the Internet on who one 152 chooses to interact with and why or how. It is not the role of this 153 memo to dictate those choices. But it is important that we 154 understand the implications of different practices. It is also 155 important that when it comes to basic Internet infrastructure, our 156 chosen technologies lead to minimal exposure with respect to the non- 157 communications threats. 159 It is particularly important to ensure that non-communications 160 security related threats are properly understood for any new Internet 161 technology. While the consideration of these issues is relatively 162 new in the IETF, this memo provides some initial ideas about 163 potential broader threat models to consider when designing protocols 164 for the Internet or when trying to defend against pervasive 165 monitoring. Further down the road, updated threat models could 166 result in changes in BCP 72 [RFC3552] (guidelines for writing 167 security considerations) and BCP 188 [RFC7258] (pervasive 168 monitoring), to include proper consideration of non-communications 169 security threats. 171 It may also be necessary to have dedicated guidance on how systems 172 design and architecture affect security. The sole consideration of 173 communications security aspects in designing Internet protocols may 174 lead to accidental or increased impact of security issues elsewhere. 175 For instance, allowing a participant to unnecessarily collect or 176 receive information may lead to a similar effect as described in 177 [RFC8546] for protocols: over time, unnecessary information will get 178 used with all the associated downsides, regardless of what deployment 179 expectations there were during protocol design. 181 This memo does not stand alone. To begin with, it is a continuation 182 of earlier work by the two authors [I-D.farrell-etm] 183 [I-D.arkko-arch-internet-threat-model] 184 [I-D.arkko-farrell-arch-model-t]. There are also other documents 185 discussing this overall space, e.g. 186 [I-D.lazanski-smart-users-internet] [I-D.arkko-arch-dedr-report]. 188 The rest of this memo is organized as follows. Section 2 makes some 189 observations about the situation, with respect to communications 190 security and beyond. The section also provides a number of real- 191 world examples. 193 Section 3 discusses some high-level principles that relate to these 194 changes, and could be used to tackle some of the emerging issues. 196 Comments are solicited on these and other aspects of this document. 197 The best place for discussion is on the model-t list. 198 (https://www.ietf.org/mailman/listinfo/model-t) 200 2. Attack Landscape 202 This section discusses the evolving landscape of security 203 vulnerabilities, threats, and attacks. 205 2.1. Communications Security Improvements 207 Being able to ask about threat model improvements is due to progress 208 already made: The fraction of Internet traffic that is 209 cryptographically protected has grown tremendously in the last few 210 years. Several factors have contributed to this change, from Snowden 211 revelations to business reasons and to better available technology 212 such as HTTP/2 [RFC7540], TLS 1.3 [RFC8446], QUIC 213 [I-D.ietf-quic-transport]. 215 In many networks, the majority of traffic has flipped from being 216 cleartext to being encrypted. Reaching the level of (almost) all 217 traffic being encrypted is no longer something unthinkable but rather 218 a likely outcome in a few years. 220 At the same time, technology developments and policy choices have 221 driven the scope of cryptographic protection from protecting only the 222 pure payload to protecting much of the rest as well, including far 223 more header and meta-data information than was protected before. For 224 instance, efforts are ongoing in the IETF to assist encrypting 225 transport headers [I-D.ietf-quic-transport], server domain name 226 information in TLS [I-D.ietf-tls-esni], and domain name queries 227 [RFC8484]. 229 There have also been improvements to ensure that the security 230 protocols that are in use actually have suitable credentials and that 231 those credentials have not been compromised, see, for instance, Let's 232 Encrypt [RFC8555], HSTS [RFC6797], HPKP [RFC7469], and Expect-CT 233 [I-D.ietf-httpbis-expect-ct]. 235 This is not to say that all problems in communications security have 236 been resolved - far from it. But the situation is definitely 237 different from what it was a few years ago. Remaining issues will be 238 and are worked on; the fight between defense and attack will also 239 continue. Communications security will stay at the top of the agenda 240 in any Internet technology development. 242 2.2. Beyond Communications Security 244 There are, however, significant issues beyond communications security 245 in the Internet. 247 To begin with, it is not necessarily clear that one can trust all the 248 endpoints in any protocol interaction, including the user's own 249 devices. Managed or closed ecosystems with multiple layers of 250 hardware and software have made it harder to understand or influence 251 what your devices do. 253 The situation is different, but not necessarily better on the side of 254 servers. Even for applications that are for user-to-user 255 communication, a typical pattern of communications is almost always 256 via an intermediary that has at least as much information as the 257 other parties have. For instance, these intermediaries are typically 258 endpoints for any transport layer security connections, and able to 259 see much communications or other messaging in cleartext. There are 260 some exceptions, of course, e.g., messaging applications with end-to- 261 end confidentiality protection. 263 For instance, while e-mail transport security [RFC7817] has become 264 much more widely deployed in recent years, progress in securing 265 e-mail messages between users has been much slower. This has lead to 266 a situation where e-mail content is considered a critical resource by 267 some mail service providers who use the content for machine learning, 268 advertisement targeting, and other purposes unrelated to message 269 delivery. Equally however, it is unclear how some useful anti-spam 270 techniques could be deployed in an end-to-end encrypted mail universe 271 (with today's end-to-end mail security protocols) and there are many 272 significant challenges should one desire to deploy end-to-end email 273 security at scale. 275 Services that are not about user-to-user to communication often 276 collect information about the user. 278 Even services that are part of the infrastructure may have security 279 issues. For instance, despite progress in protecting DNS query 280 protocols with encryption (see, e.g., [RFC7858] and [RFC8484]), DNS 281 resolver services themselves may be targets for attack or sources for 282 leaks. For instance, the services may collect information or be 283 vulnerable targets of denial-of-service attacks, attacks to steal 284 user browsing history information, or be the target of surveillance 285 activities and government information requests. Infrastructure 286 services with information about a large number of users is collected 287 in small number of services are particularly attractive targets for 288 these attacks. 290 With the growth of trading users' information by many of these 291 parties, it becomes necessary to take precautions against endpoints 292 that are compromised, malicious, or whose interests simply do not 293 align with the interests of the users. 295 In general, many recent attacks relate more to information than 296 communications. For instance, personal information leaks typically 297 happen via information stored on a compromised server rather than 298 capturing communications. There is little hope that such attacks can 299 be prevented entirely. Again, the best course of action seems to be 300 avoid the disclosure of information in the first place, or at least 301 to not perform that in a manner that makes it possible that others 302 can readily use the information. 304 2.3. Types of Attacks 306 This section discusses a few classes of attacks that are relevant for 307 our consideration. 309 2.3.1. Misuse of Accidental Vulnerabilities 311 Not all adversarial behaviour starts as deliberate, some is initiated 312 due to various levels of carelessness and/or due to erroneous 313 assumptions about the environments in which those applications 314 currently run at. Nevertheless, a leak or vulnerability can be 315 exploited by others that misuse the data for their own purposes. 317 Some attacks in this category include: 319 o Virtualisation exposing secrets, for example, Meltdown and Spectre 320 [MeltdownAndSpectre] [Kocher2019] [Lipp2018] and other similar 321 side-channel attacks. 323 o Compromised badly-maintained web sites or services, e.g., 324 [Passwords] or Amazon S3 leaks. 326 o Supply-chain attacks, for example, the [TargetAttack] or malware 327 within pre-installed applications on Android phones [Bloatware]. 329 o Breaches of major service providers, that many of us might have 330 assumed would be sufficiently capable to be the best large-scale 331 "Identity providers", for example, Yahoo 332 (https://www.wired.com/story/yahoo-breach-three-billion- 333 accounts/), Facebook (https://www.pcmag.com/news/367319/facebook- 334 stored-up-to-600m-user-passwords-in-plain-text and 335 https://www.cnet.com/news/facebook-breach-affected-50-million- 336 people/), Telcos (https://www.zdnet.com/article/us-telcos-caught- 337 selling-your-location-data-again-senator-demands-new-laws/ and 338 https://www.zdnet.com/article/millions-verizon-customer-records- 339 israeli-data/), Google (https://www.wsj.com/articles/google- 340 exposed-user-data-feared-repercussions-of-disclosing-to-public- 341 1539017194), and Microsoft 342 (https://motherboard.vice.com/en_us/article/ywyz3x/hackers-could- 343 read-your-hotmail-msn-outlook-microsoft-customer-support). 345 2.3.2. Misbehaving Applications 347 There are many examples of application developers doing their best to 348 protect the security and privacy of their users or customers. That's 349 just the same as the case today where we need to consider in-network 350 actors as potential adversaries despite the many examples of network 351 operators who both act in the best interests of their users and 352 succeed in defending against attacks from others. 354 In short, there are applications that do not act in the best 355 interests of their users. 357 This can also happen indirectly. Despite the best efforts of 358 curators, so-called App-Stores frequently distribute malware of many 359 kinds and one recent study [Curated] claims that simple obfuscation 360 enables malware to avoid detection by even sophisticated operators. 361 Given the scale of these deployments, distribution of even a small 362 percentage of malware-infected applications can affect a large number 363 of people. The end result is an application that 365 Applications may also mislead users. Many web sites today provide 366 some form of privacy policy and terms of service, that are known to 367 be mostly unread [Unread]. This implies that, legal fiction aside, 368 users of those sites have not in reality agreed to the specific terms 369 published and so users are therefore highly exposed to being 370 exploited by web sites, for example [Cambridge] is a recent well- 371 publicised case where a service provider abused the data of 87 372 million users via a partnership. While many web site operators claim 373 that they care deeply about privacy, it seems prudent to assume that 374 some do not in fact care about user privacy in ways with which many 375 of their users would agree. 377 2.3.3. Network Infrastructure Attacks 379 The network infrastructure may also work in an inappropriate manner. 380 For instance, a Virtual Private Network (VPN) may misrepresent how it 381 carries the users' traffic, for example misrepresenting the countries 382 in which they provide vantage points [Vpns]. A user's home network 383 equipment may also be malicous or compromised. For example, one 384 study [Home] reports on a 2011 attack that affected 4.5 million DSL 385 modems in Brazil. The absence of software update [RFC8240] has been 386 a major cause of these issues and rises to the level that considering 387 this as intentional behaviour by device vendors who have chosen this 388 path is warranted. 390 2.3.4. Untrustworthy Devices 392 Traditionally, there's been an implied trust in various parts of the 393 system - such as the user's own device, nodes inside a particular 394 network perimeter, or nodes under a single administrative control. 396 Client endpoint implementations were never fully trusted, but the 397 environments in which those endpoints exist are changing. Users may 398 not have as much control over their own devices as they used to, due 399 to manufacturer-controlled operating system installations and locked 400 device ecosystems. And within those ecosystems, even the 401 applications that are available tend to have privileges that users by 402 themselves might not desire those applications be granted, such as 403 excessive rights to media, location, and peripherals. There are also 404 designated efforts by various authorities to hack end-user devices as 405 a means of intercepting data about the user. 407 Examples of these issues are too many to list, for instance, so- 408 called "smart" televisions spying on their owners and one survey of 409 user attitudes [SmartTV]. 411 There are similar issues with larger, networked systems. As these 412 systems evolve over time, they get used and connected in different 413 ways, run in virtual environments, and expanded for new functions. 414 Old assumptions and security mechanisms may no longer be applicable 415 in these new environments, leading to security vulnerabilities. 417 Even in a closed network with carefully managed components there may 418 be compromised components, as evidenced in the most extreme way by 419 the Stuxnet worm that operated in an airgapped network. 421 Every system runs large amount of software, and it is often not 422 practical or even possible to prevent compromised code even in a 423 high-security setting, let alone in commercial or private networks. 424 Installation media, physical ports, both open source and proprietary 425 programs, firmware, or even innocent-looking components on a circuit 426 board can be suspect [TinyChip]. In addition, complex underlying 427 computing platforms, such as modern CPUs with underlying security and 428 management tools are prone to problems. Analysis for the security of 429 many interesting real-world systems now commonly needs to include 430 cross-component attacks, e.g., the use of car radios and other 431 externally communicating devices as part of attacks launched against 432 the control components such as brakes in a car [Savage]. 434 Untrustworthy systems can also cause damage to other parties. 435 Examples of this range from attacks of badly constructed IoT devices 436 [DynDDoS] to large Internet services that become single points of 437 failure [I-D.arkko-arch-infrastructure-centralisation]. 439 2.3.5. Tracking 441 One of the biggest threats to user privacy on the Web is ubiquitous 442 tracking. This is often done to support advertising based business 443 models. 445 While some people may be sanguine about this kind of tracking, others 446 consider this behaviour unwelcome, when or if they are informed that 447 it happens, [Attitude] though the evidence here seems somewhat harder 448 to interpret and many studies (that we have found to date) involve 449 small numbers of users. Historically, browsers have not made this 450 kind of tracking visible and have enabled it by default, though some 451 recent browser versions are starting to enable visibility and 452 blocking of some kinds of tracking. Browsers are also increasingly 453 imposing more stringent requirements on plug-ins for varied security 454 reasons. 456 Third party tracking 458 One form of tracking is by third parties. HTTP header fields (such 459 as cookies, [RFC6265]) are commonly used for such tracking, as are 460 structures within the content of HTTP responses such as links to 1x1 461 pixel images and (ab)use of Javascript APIs offered by browsers 462 [Tracking]. 464 Whenever a resource is loaded from a server, that server can include 465 a cookie which will be sent back to the server on future loads. This 466 includes situations where the resource is loaded as a resource on a 467 page, such as an image or a JavaScript module. When loading a 468 resource, the server is aware of the top-level page that the resource 469 is used on, through the use of the Referer HTTP header [RFC7231]. 470 those loads include a Referer header which contains the top-level 471 page from which that subresource is being loaded. 473 The combination of these features makes it possible to track a user 474 across the Web. The tracker convinces a number of content sites 475 ("first parties") to include a resource from the tracker site. This 476 resource can perform some function such as displaying an 477 advertisement or providing analytics to the first party site. But 478 the resource may also be simply a tracker. When the user visits one 479 of the content sites, the tracker receives both a Referer header and 480 the cookie. For an individual user with a particular browser, the 481 cookie is the same regardless of which site the tracker is on. This 482 allows the tracker to observe what pages within the set of content 483 sites the user visits. The resulting information is commonly used 484 for targeting advertisements, but it can also be used for other 485 purposes. 487 This capability itself constitutes a major threat to user privacy. 488 Additional techniques such as cookie syncing, identifier correlation, 489 and fingerprinting make the problem even worse. 491 As a given tracker will not be on all sites, that tracker has 492 incomplete coverage. However, trackers often collude (a practice 493 called "cookie syncing") to combine the information from different 494 tracking cookies. 496 Sometimes trackers will be embedded on a site which collects a user 497 identifier, such as social media identity or an e-mail address. If 498 the site can inform the tracker of the identifier, that allows the 499 tracker to tie the identifier to the cookie. 501 While a browser may block cookies, fingerprinting browsers often 502 allows tracking the users. For instance, features such as User-Agent 503 string, plugin and font support, screen resolution, and timezone can 504 yield a fingerprint that is sometimes unique to a single user 505 [AmIUnique] and which persists beyond cookie scope and lifetime. 506 Even in cases where this fingerprint is not unique, the anonymity set 507 may be sufficiently small that, coupled with other data, this yields 508 a unique, per-user identifier. Fingerprinting of this type is more 509 prevalent on systems and platforms where data-set features are 510 flexible, such as desktops, where plugins are more commonly in use. 511 Fingerprinting prevention is an active research area; see [Boix2018] 512 for more information. 514 Other types of tracking linked to web tracking 516 Third party web tracking is not the only concern. An obvious 517 tracking danger exists also in popular ecosystems - such as social 518 media networks - that house a large part of many users' online 519 existence. There is no need for a third party to track the user's 520 browsing as all actions are performed within a single site, where 521 most messaging, viewing, and sharing activities happen. 523 Browsers themselves or services used by the browser can also become a 524 potential source of tracking users. For instance, the URL/search bar 525 service may leak information about the user's actions to a search 526 provider via an "autocomplete" feature. [Leith2020] 528 Tracking through users' IP addresses or DNS queries is also a danger. 529 This may happen by directly observing the cleartext IP or DNS 530 traffic, though DNS tracking may be preventable via DNS protocols 531 that are secured end-to-end. But the DNS queries are also (by 532 definition) seen by the used DNS recursive resolver service, which 533 may accidentally or otherwise track the users' activities. This is 534 particularly problematic if a large number of users employ either a 535 commonly used ISP service or an Internet-based resolver service 536 [I-D.arkko-arch-infrastructure-centralisation]. In contrast, use of 537 a DNS recursive that sees little traffic could equally be used for 538 tracking. Similarly, other applications, such an mail or instant 539 messaging protocols, that can carry HTML content can be integrated 540 with web tracking. For instance, intentional tracking are also seen 541 many times per day by email users - in one study [Mailbug] the 542 authors estimated that 62% of leakage to third parties was 543 intentional, for example if leaked data included a hash of the 544 recipient email address. 546 Tracking happens through other systems besides the web, of course. 547 For instance, some mail user agents (MUAs) render HTML content by 548 default (with a subset not allowing that to be turned off, perhaps 549 particularly on mobile devices) and thus enable the same kind of 550 adversarial tracking seen on the web. Attempts at such intentional 551 tracking are also seen many times per day by email users - in one 552 study [Mailbug] the authors estimated that 62% of leakage to third 553 parties was intentional, for example if leaked data included a hash 554 of the recipient email address. 556 3. Principles 558 Based on the above issues, it is necessary to pay attention to the 559 following aspects: 561 o Security of devices, including the user's own devices. 563 o Security of data at rest, in various parts of the system. 565 o Tracking and identification of users and their devices. 567 o Role of intermediaries, and in particular information passing 568 through them. 570 These topics are discussed below. There are obviously many detailed 571 technical questions and approaches to tackling them. However, in 572 this memo we wish to focus on higher level architectural principles 573 that might guide us in thinking about about the topics. 575 3.1. Trusting Devices 577 In general, this means that one cannot entirely trust even a closed 578 system where you picked all the components yourself, let alone 579 typical commercial, networked and Internet-connected systems. 581 PRINCIPLE: Consider all system components as potentially 582 untrustworthy, and consider the implications of their compromise. 584 There may also be ways to mitigate damages, should a compromise 585 occur. 587 3.2. Protecting Information 589 Data leaks have become the primary concern. Even trusted, well- 590 managed parties can be problematic, such as when large data stores 591 attract attempts to use that data in a manner that is not consistent 592 with the users' interests. 594 Mere encryption of communications is not sufficient to protect 595 information. 597 PRINCIPLE: Consider information passed to another party as a 598 publication to at least some number of entities. 600 This principle applies even if the communications that carry that 601 information are encrypted. 603 3.3. Tracking 605 Information leakage is particularly harmful in situations where the 606 information can be traced to an individual, such as is the case with 607 any information that users would consider private, be it about 608 messages to another users, browsing history, or even user's medical 609 information. 611 PRINCIPLE: Assume that every interaction with another party can 612 result in fingerprinting or identification of the user in 613 question. 615 In many cases there are readily available user identifiers in data 616 that is leaked, such as was the case with a recent medical 617 information leak in Finland [Vastaamo]. But even when such 618 identifiers are not present, in many communication methods, there is 619 ample opportunity for narrowing down which entity is connecting, 620 through geolocation, fingerprinting, and correlation with other 621 information. 623 3.4. Role of End-to-End 625 [RFC1958] notes that "end-to-end functions can best be realised by 626 end-to-end protocols": 628 The basic argument is that, as a first principle, certain required 629 end-to-end functions can only be performed correctly by the end- 630 systems themselves. A specific case is that any network, however 631 carefully designed, will be subject to failures of transmission at 632 some statistically determined rate. The best way to cope with 633 this is to accept it, and give responsibility for the integrity of 634 communication to the end systems. Another specific case is end- 635 to-end security. 637 The "end-to-end argument" was originally described by Saltzer et al 638 [Saltzer]. They said: 640 The function in question can completely and correctly be 641 implemented only with the knowledge and help of the application 642 standing at the endpoints of the communication system. Therefore, 643 providing that questioned function as a feature of the 644 communication system itself is not possible. 646 These functional arguments align with other, practical arguments 647 about the evolution of the Internet under the end-to-end model. The 648 endpoints evolve quickly, often with simply having one party change 649 the necessary software on both ends. Whereas waiting for network 650 upgrades would involve potentially a large number of parties from 651 application owners to multiple network operators. The end-to-end 652 model supports permissionless innovation where new innovation can 653 flourish in the Internet without excessive wait for other parties to 654 act. 656 But the details matter. What is considered an endpoint? What 657 characteristics of Internet are we trying to optimize? 659 There is a significant difference between actual endpoints from a 660 user's interaction perspective (e.g., another user) and from a system 661 perspective (e.g., a third party relaying a message). Such 662 intermediaries can provide a useful service. As [I-D.thomson-tmi] 663 points out, networks themselves would not exist without 664 intermediaries that can forward communications to others. 666 PRINCIPLE: Limit the use of intermediaries, and what they can do. 668 PRINCIPLE: Pass information only between the "real ends" of a 669 conversation, unless the information is necessary for a useful 670 function in an intermediary. 672 For instance, a transport connection between two components of a 673 system is not an end-to-end connection even if it encompasses all the 674 protocol layers up to the application layer. It is not end-to-end, 675 if the information or control function it carries actually extends 676 beyond those components. For instance, just because an e-mail server 677 can read the contents of an e-mail message does not make it a 678 legitimate recipient of the e-mail. 680 This memo also proposes to focus on the "need to know" aspect in 681 systems. Information should not be disclosed, stored, or routed in 682 cleartext through parties that do not absolutely need to have that 683 information. This relates to the discussion in [I-D.thomson-tmi], in 684 that the valuable functions provided by intermediaries need to be 685 balanced against the information that they need to perform their 686 function. And, in a lot of cases unnecessary information is provided 687 to intermediaries, which leads to privacy and other problems. 689 4. Security Considerations 691 The entire memo covers the security considerations. 693 5. IANA Considerations 695 There are no IANA considerations in this work. 697 6. Informative References 699 [AbuseCases] 700 McDermott, J. and C. Fox, "Using abuse case models for 701 security requirements analysis", IEEE Annual Computer 702 Security Applications Conference (ACSAC'99), 703 https://www.acsac.org/1999/papers/wed-b-1030-john.pdf , 704 1999. 706 [AmIUnique] 707 INRIA, ., "Am I Unique?", https://amiunique.org , 2020. 709 [Attitude] 710 "User Perceptions of Sharing, Advertising, and Tracking", 711 Symposium on Usable Privacy and Security (SOUPS), 712 https://www.usenix.org/conference/soups2015/proceedings/ 713 presentation/chanchary , 2015. 715 [avleak] Cox, J., "Leaked Documents Expose the Secretive Market for 716 Your Web Browsing Data", 717 https://www.vice.com/en_us/article/qjdkq7/ 718 avast-antivirus-sells-user-browsing-data-investigation , 719 2020. 721 [BgpHijack] 722 Sermpezis, P., Kotronis, V., Dainotti, A., and X. 723 Dimitropoulos, "A survey among network operators on BGP 724 prefix hijacking", ACM SIGCOMM Computer Communication 725 Review 48, no. 1 (2018): 64-69, 726 https://arxiv.org/pdf/1801.02918.pdf , 2018. 728 [Bloatware] 729 Gamba, G., Rashed, M., Razaghpanah, A., Tapiado, J., and 730 N. Vallina, "An Analysis of Pre-installed Android 731 Software", arXiv preprint arXiv:1905.02713 (2019) , 2019. 733 [Boix2018] 734 Gomez-Boix, A., Laperdrix, P., and B. Baudry, "Hiding in 735 the crowd: an analysis of the effectiveness of browser 736 fingerprinting at large scale", Proceedings of the 2018 737 world wide web conference , 2018. 739 [Cambridge] 740 Isaak, J. and M. Hanna, "User Data Privacy: Facebook, 741 Cambridge Analytica, and Privacy Protection", Computer 742 51.8 (2018): 56-59, https://ieeexplore.ieee.org/stamp/ 743 stamp.jsp?arnumber=8436400 , 2018. 745 [CommandAndControl] 746 Botnet, ., "Creating botnet C&C server. What architecture 747 should I use? IRC? HTTP?", Stackexchange.com question, 748 https://security.stackexchange.com/questions/100577/ 749 creating-botnet-cc-server-what-architecture-should-i-use- 750 irc-http , 2014. 752 [Curated] Hammad, M., Garcia, J., and S. MaleK, "A large-scale 753 empirical study on the effects of code obfuscations on 754 Android apps and anti-malware products", ACM International 755 Conference on Software Engineering 2018, 756 https://www.ics.uci.edu/~seal/ 757 publications/2018ICSE_Hammad.pdf , 2018. 759 [DeepDive] 760 Krebs on Security, ., "A Deep Dive on the Recent 761 Widespread DNS Hijacking Attacks", krebsonsecurity.com 762 blog, https://krebsonsecurity.com/2019/02/a-deep-dive-on- 763 the-recent-widespread-dns-hijacking-attacks/ , 2019. 765 [DoubleKey] 766 Witte, D., "Thirdparty", 767 https://wiki.mozilla.org/Thirdparty , June 2010. 769 [DynDDoS] York, K., "Dyn's Statement on the 10/21/2016 DNS DDoS 770 Attack", Company statement: https://dyn.com/blog/ 771 dyn-statement-on-10212016-ddos-attack/ , 2016. 773 [GDPRAccess] 774 EU, ., "Right of access by the data subject", Article 15, 775 GDPR, https://gdpr-info.eu/art-15-gdpr/ , n.d.. 777 [HijackDet] 778 Schlamp, J., Holz, R., Gasser, O., Korste, A., Jacquemart, 779 Q., Carle, G., and E. Biersack, "Investigating the nature 780 of routing anomalies: Closing in on subprefix hijacking 781 attacks", International Workshop on Traffic Monitoring and 782 Analysis, pp. 173-187. Springer, Cham, 783 https://www.net.in.tum.de/fileadmin/bibtex/publications/ 784 papers/schlamp_TMA_1_2015.pdf , 2015. 786 [Home] Nthala, N. and I. Flechais, "Rethinking home network 787 security", European Workshop on Usable Security 788 (EuroUSEC), https://ora.ox.ac.uk/objects/ 789 uuid:e2460f50-579b-451b-b14e-b7be2decc3e1/download_file?sa 790 fe_filename=bare_conf_EuroUSEC2018.pdf&file_format=applica 791 tion%2Fpdf&type_of_work=Conference+item , 2018. 793 [I-D.arkko-arch-dedr-report] 794 Arkko, J. and T. Hardie, "Report from the IAB workshop on 795 Design Expectations vs. Deployment Reality in Protocol 796 Development", draft-arkko-arch-dedr-report-00 (work in 797 progress), November 2019. 799 [I-D.arkko-arch-infrastructure-centralisation] 800 Arkko, J., "Centralised Architectures in Internet 801 Infrastructure", draft-arkko-arch-infrastructure- 802 centralisation-00 (work in progress), November 2019. 804 [I-D.arkko-arch-internet-threat-model] 805 Arkko, J., "Changes in the Internet Threat Model", draft- 806 arkko-arch-internet-threat-model-01 (work in progress), 807 July 2019. 809 [I-D.arkko-farrell-arch-model-t] 810 Arkko, J. and S. Farrell, "Challenges and Changes in the 811 Internet Threat Model", draft-arkko-farrell-arch-model- 812 t-04 (work in progress), July 2020. 814 [I-D.farrell-etm] 815 Farrell, S., "We're gonna need a bigger threat model", 816 draft-farrell-etm-03 (work in progress), July 2019. 818 [I-D.iab-protocol-maintenance] 819 Thomson, M., "The Harmful Consequences of the Robustness 820 Principle", draft-iab-protocol-maintenance-04 (work in 821 progress), November 2019. 823 [I-D.ietf-httpbis-expect-ct] 824 estark@google.com, e., "Expect-CT Extension for HTTP", 825 draft-ietf-httpbis-expect-ct-08 (work in progress), 826 December 2018. 828 [I-D.ietf-mls-architecture] 829 Omara, E., Beurdouche, B., Rescorla, E., Inguva, S., Kwon, 830 A., and A. Duric, "The Messaging Layer Security (MLS) 831 Architecture", draft-ietf-mls-architecture-05 (work in 832 progress), July 2020. 834 [I-D.ietf-quic-transport] 835 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 836 and Secure Transport", draft-ietf-quic-transport-32 (work 837 in progress), October 2020. 839 [I-D.ietf-rats-eat] 840 Mandyam, G., Lundblade, L., Ballesteros, M., and J. 841 O'Donoghue, "The Entity Attestation Token (EAT)", draft- 842 ietf-rats-eat-04 (work in progress), August 2020. 844 [I-D.ietf-teep-architecture] 845 Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler, 846 "Trusted Execution Environment Provisioning (TEEP) 847 Architecture", draft-ietf-teep-architecture-12 (work in 848 progress), July 2020. 850 [I-D.ietf-teep-protocol] 851 Tschofenig, H., Pei, M., Wheeler, D., Thaler, D., and A. 852 Tsukamoto, "Trusted Execution Environment Provisioning 853 (TEEP) Protocol", draft-ietf-teep-protocol-03 (work in 854 progress), July 2020. 856 [I-D.ietf-tls-esni] 857 Rescorla, E., Oku, K., Sullivan, N., and C. Wood, "TLS 858 Encrypted Client Hello", draft-ietf-tls-esni-08 (work in 859 progress), October 2020. 861 [I-D.ietf-tls-grease] 862 Benjamin, D., "Applying GREASE to TLS Extensibility", 863 draft-ietf-tls-grease-04 (work in progress), August 2019. 865 [I-D.lazanski-smart-users-internet] 866 Lazanski, D., "An Internet for Users Again", draft- 867 lazanski-smart-users-internet-00 (work in progress), July 868 2019. 870 [I-D.mcfadden-smart-endpoint-taxonomy-for-cless] 871 McFadden, M., "Endpoint Taxonomy for CLESS", draft- 872 mcfadden-smart-endpoint-taxonomy-for-cless-02 (work in 873 progress), July 2020. 875 [I-D.nottingham-for-the-users] 876 Nottingham, M., "The Internet is for End Users", draft- 877 nottingham-for-the-users-09 (work in progress), July 2019. 879 [I-D.taddei-smart-cless-introduction] 880 Taddei, A., Wueest, C., Roundy, K., and D. Lazanski, 881 "Capabilities and Limitations of an Endpoint-only Security 882 Solution", draft-taddei-smart-cless-introduction-03 (work 883 in progress), July 2020. 885 [I-D.thomson-tmi] 886 Thomson, M., "Principles for the Involvement of 887 Intermediaries in Internet Protocols", draft-thomson- 888 tmi-00 (work in progress), July 2020. 890 [I-D.wood-pearg-website-fingerprinting] 891 Goldberg, I., Wang, T., and C. Wood, "Network-Based 892 Website Fingerprinting", draft-wood-pearg-website- 893 fingerprinting-00 (work in progress), November 2019. 895 [Jager2015] 896 Jager, T., Schwenk, J., and J. Somorovsky, "On the 897 Security of TLS 1.3 and QUIC Against Weaknesses in PKCS#1 898 v1.5 Encryption", Proceedings of ACM CCS 2015, DOI 899 10.1145/2810103.2813657, https://www.nds.rub.de/media/nds/ 900 veroeffentlichungen/2015/08/21/Tls13QuicAttacks.pdf , 901 October 2015. 903 [Kocher2019] 904 Kocher, P., Horn, J., Fogh, A., Genkin, D., Gruss, D., 905 Haas, W., Hamburg, M., Lipp, M., Mangard, S., Prescher, 906 T., Schwarz, M., and Y. Yarom, "Spectre Attacks: 907 Exploiting Speculative Execution", 40th IEEE Symposium on 908 Security and Privacy (S&P'19) , 2019. 910 [LeakyBuckets] 911 Chickowski, E., "Leaky Buckets: 10 Worst Amazon S3 912 Breaches", Bitdefender blog, 913 https://businessinsights.bitdefender.com/ 914 worst-amazon-breaches , 2018. 916 [Leith2020] 917 Leith, D., "Web Browser Privacy: What Do Browsers Say When 918 They Phone Home?", In submission, 919 https://www.scss.tcd.ie/Doug.Leith/pubs/ 920 browser_privacy.pdf , March 2020. 922 [Lipp2018] 923 Lipp, M., Schwarz, M., Gruss, D., Prescher, T., Haas, W., 924 Fogh, A., Horn, J., Mangard, S., Kocher, P., Genkin, D., 925 Yarom, Y., and M. Hamburg, "Meltdown: Reading Kernel 926 Memory from User Space", 27th USENIX Security Symposium 927 (USENIX Security 18) , 2018. 929 [Mailbug] Englehardt, S., Han, J., and A. Narayanan, "I never signed 930 up for this! Privacy implications of email tracking", 931 Proceedings on Privacy Enhancing Technologies 2018.1 932 (2018): 109-126, https://www.degruyter.com/downloadpdf/j/ 933 popets.2018.2018.issue-1/popets-2018-0006/ 934 popets-2018-0006.pdf , 2018. 936 [MeltdownAndSpectre] 937 CISA, ., "Meltdown and Spectre Side-Channel Vulnerability 938 Guidance", Alert (TA18-004A), 939 https://www.us-cert.gov/ncas/alerts/TA18-004A , 2018. 941 [Mozilla2019] 942 Camp, D., "Firefox Now Available with Enhanced Tracking 943 Protection by Default Plus Updates to Facebook Container, 944 Firefox Monitor and Lockwise", The Mozilla Blog, 945 https://blog.mozilla.org/blog/2019/06/04/firefox-now- 946 available-with-enhanced-tracking-protection-by-default/ , 947 June 2019. 949 [Passwords] 950 com, haveibeenpwned., "Pwned Passwords", Website 951 https://haveibeenpwned.com/Passwords , 2019. 953 [RFC1958] Carpenter, B., Ed., "Architectural Principles of the 954 Internet", RFC 1958, DOI 10.17487/RFC1958, June 1996, 955 . 957 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 958 Text on Security Considerations", BCP 72, RFC 3552, 959 DOI 10.17487/RFC3552, July 2003, 960 . 962 [RFC3935] Alvestrand, H., "A Mission Statement for the IETF", 963 BCP 95, RFC 3935, DOI 10.17487/RFC3935, October 2004, 964 . 966 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 967 Element (PCE)-Based Architecture", RFC 4655, 968 DOI 10.17487/RFC4655, August 2006, 969 . 971 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 972 DOI 10.17487/RFC6265, April 2011, 973 . 975 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 976 DOI 10.17487/RFC6454, December 2011, 977 . 979 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 980 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 981 February 2012, . 983 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 984 RFC 6749, DOI 10.17487/RFC6749, October 2012, 985 . 987 [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict 988 Transport Security (HSTS)", RFC 6797, 989 DOI 10.17487/RFC6797, November 2012, 990 . 992 [RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0 993 Threat Model and Security Considerations", RFC 6819, 994 DOI 10.17487/RFC6819, January 2013, 995 . 997 [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate 998 Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, 999 . 1001 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 1002 Morris, J., Hansen, M., and R. Smith, "Privacy 1003 Considerations for Internet Protocols", RFC 6973, 1004 DOI 10.17487/RFC6973, July 2013, 1005 . 1007 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1008 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 1009 DOI 10.17487/RFC7231, June 2014, 1010 . 1012 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1013 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 1014 2014, . 1016 [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning 1017 Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 1018 2015, . 1020 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 1021 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 1022 DOI 10.17487/RFC7540, May 2015, 1023 . 1025 [RFC7817] Melnikov, A., "Updated Transport Layer Security (TLS) 1026 Server Identity Check Procedure for Email-Related 1027 Protocols", RFC 7817, DOI 10.17487/RFC7817, March 2016, 1028 . 1030 [RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830, 1031 DOI 10.17487/RFC7830, May 2016, 1032 . 1034 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 1035 and P. Hoffman, "Specification for DNS over Transport 1036 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 1037 2016, . 1039 [RFC8240] Tschofenig, H. and S. Farrell, "Report from the Internet 1040 of Things Software Update (IoTSU) Workshop 2016", 1041 RFC 8240, DOI 10.17487/RFC8240, September 2017, 1042 . 1044 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1045 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1046 . 1048 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 1049 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 1050 . 1052 [RFC8546] Trammell, B. and M. Kuehlewind, "The Wire Image of a 1053 Network Protocol", RFC 8546, DOI 10.17487/RFC8546, April 1054 2019, . 1056 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 1057 Kasten, "Automatic Certificate Management Environment 1058 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 1059 . 1061 [Saltzer] Saltzer, J., Reed, D., and D. Clark, "End-To-End Arguments 1062 in System Design", ACM TOCS, Vol 2, Number 4, pp 277-288 , 1063 November 1984. 1065 [Savage] Savage, S., "Modern Automotive Vulnerabilities: Causes, 1066 Disclosures, and Outcomes", USENIX , 2016. 1068 [SmartTV] Malkin, N., Bernd, J., Johnson, M., and S. Egelman, "What 1069 Can't Data Be Used For? Privacy Expectations about Smart 1070 TVs in the U.S.", European Workshop on Usable Security 1071 (Euro USEC), https://www.ndss-symposium.org/wp- 1072 content/uploads/2018/06/ 1073 eurousec2018_16_Malkin_paper.pdf" , 2018. 1075 [StackEvo] 1076 Trammell, B., Thomson, M., Howard, L., and T. Hardie, 1077 "What Is an Endpoint?", Unpublished work, 1078 https://github.com/stackevo/endpoint-draft/blob/master/ 1079 draft-trammell-whats-an-endpoint.md , 2017. 1081 [Sybil] Viswanath, B., Post, A., Gummadi, K., and A. Mislove, "An 1082 analysis of social network-based sybil defenses", ACM 1083 SIGCOMM Computer Communication Review 41(4), 363-374, 1084 https://conferences.sigcomm.org/sigcomm/2010/papers/ 1085 sigcomm/p363.pdf , 2011. 1087 [TargetAttack] 1088 Osborne, C., "How hackers stole millions of credit card 1089 records from Target", ZDNET, 1090 https://www.zdnet.com/article/how-hackers-stole-millions- 1091 of-credit-card-records-from-target/ , 2014. 1093 [TinyChip] 1094 Robertson, J. and M. Riley, "The Big Hack: How China Used 1095 a Tiny Chip to Infiltrate U.S. Companies", 1096 https://www.bloomberg.com/news/features/2018-10-04/the- 1097 big-hack-how-china-used-a-tiny-chip-to-infiltrate-america- 1098 s-top-companies , October 2018. 1100 [Toys] Chu, G., Apthorpe, N., and N. Feamster, "Security and 1101 Privacy Analyses of Internet of Things Childrens' Toys", 1102 IEEE Internet of Things Journal 6.1 (2019): 978-985, 1103 https://arxiv.org/pdf/1805.02751.pdf , 2019. 1105 [Tracking] 1106 Ermakova, T., Fabian, B., Bender, B., and K. Klimek, "Web 1107 Tracking-A Literature Review on the State of Research", 1108 Proceedings of the 51st Hawaii International Conference on 1109 System Sciences, https://scholarspace.manoa.hawaii.edu/ 1110 bitstream/10125/50485/paper0598.pdf , 2018. 1112 [Troll] Stewart, L., Arif, A., and K. Starbird, "Examining trolls 1113 and polarization with a retweet network", ACM Workshop on 1114 Misinformation and Misbehavior Mining on the Web, 1115 https://faculty.washington.edu/kstarbi/ 1116 examining-trolls-polarization.pdf , 2018. 1118 [Unread] Obar, J. and A. Oeldorf, "The biggest lie on the 1119 internet{:} Ignoring the privacy policies and terms of 1120 service policies of social networking services", 1121 Information, Communication and Society (2018): 1-20 , 1122 2018. 1124 [Vastaamo] 1125 Redcross Finland, ., "Read this if your personal data was 1126 leaked in the Vastaamo data system break-in", 1127 https://www.redcross.fi/news/20201029/read-if-your- 1128 personal-data-was-leaked-vastaamo-data-system-break , 1129 October 2020. 1131 [Vpns] Khan, M., DeBlasio, J., Voelker, G., Snoeren, A., Kanich, 1132 C., and N. Vallina, "An empirical analysis of the 1133 commercial VPN ecosystem", ACM Internet Measurement 1134 Conference 2018 (pp. 443-456), 1135 https://eprints.networks.imdea.org/1886/1/ 1136 imc18-final198.pdf , 2018. 1138 Appendix A. Contributors 1140 Eric Rescorla and Chris Wood provided much of the text in 1141 Section 2.3.5. Martin Thomson's excellent document [I-D.thomson-tmi] 1142 also inspired some of the work in Section 3. 1144 Appendix B. Acknowledgements 1146 The authors would like to thank the IAB: 1148 Alissa Cooper, Wes Hardaker, Ted Hardie, Christian Huitema, Zhenbin 1149 Li, Erik Nordmark, Mark Nottingham, Melinda Shore, Jeff Tantsura, 1150 Martin Thomson, Brian Trammel, Mirja Kuhlewind, and Colin Perkins. 1152 The authors would also like to thank the participants of the IETF 1153 SAAG meeting where this topic was discussed: 1155 Harald Alvestrand, Roman Danyliw, Daniel Kahn Gilmore, Wes Hardaker, 1156 Bret Jordan, Ben Kaduk, Dominique Lazanski, Eliot Lear, Lawrence 1157 Lundblade, Kathleen Moriarty, Kirsty Paine, Eric Rescorla, Ali 1158 Rezaki, Mohit Sethi, Ben Schwartz, Dave Thaler, Paul Turner, David 1159 Waltemire, and Jeffrey Yaskin. 1161 The authors would also like to thank the participants of the IAB 2019 1162 DEDR workshop: 1164 Tuomas Aura, Vittorio Bertola, Carsten Bormann, Stephane Bortzmeyer, 1165 Alissa Cooper, Hannu Flinck, Carl Gahnberg, Phillip Hallam-Baker, Ted 1166 Hardie, Paul Hoffman, Christian Huitema, Geoff Huston, Konstantinos 1167 Komaitis, Mirja Kuhlewind, Dirk Kutscher, Zhenbin Li, Julien 1168 Maisonneuve, John Mattson, Moritz Muller, Joerg Ott, Lucas Pardue, 1169 Jim Reid, Jan-Frederik Rieckers, Mohit Sethi, Melinda Shore, Jonne 1170 Soininen, Andrew Sullivan, and Brian Trammell. 1172 The authors would also like to thank the participants of the November 1173 2016 meeting at the IETF: 1175 Carsten Bormann, Randy Bush, Tommy C, Roman Danyliw, Ted Hardie, 1176 Christian Huitema, Ben Kaduk, Dirk Kutscher, Dominique Lazanski, Eric 1177 Rescorla, Ali Rezaki, Mohit Sethi, Melinda Shore, Martin Thomson, and 1178 Robin Wilton ... (missing many people... did we have minutes other 1179 than the list of actions?) ... 1181 Thanks for specific comments on this text to: Ronald van der Pol. 1183 Finally, the authors would like to thank numerous other people for 1184 insightful comments and discussions in this space. 1186 Authors' Addresses 1188 Jari Arkko 1189 Ericsson 1190 Valitie 1B 1191 Kauniainen 1192 Finland 1194 Email: jari.arkko@piuha.net 1196 Stephen Farrell 1197 Trinity College Dublin 1198 College Green 1199 Dublin 1200 Ireland 1202 Email: stephen.farrell@cs.tcd.ie