idnits 2.17.1 draft-arkko-arch-internet-threat-model-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 09, 2019) is 1753 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.nottingham-for-the-users' is defined on line 767, but no explicit reference was found in the text == Unused Reference: 'RFC6973' is defined on line 798, but no explicit reference was found in the text == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-20 == Outdated reference: A later version (-18) exists of draft-ietf-tls-esni-03 == Outdated reference: A later version (-09) exists of draft-nottingham-for-the-users-08 -- Obsolete informational reference (is this intentional?): RFC 7540 (Obsoleted by RFC 9113) Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 2 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 July 09, 2019 5 Expires: January 10, 2020 7 Changes in the Internet Threat Model 8 draft-arkko-arch-internet-threat-model-01 10 Abstract 12 Communications security has been at the center of many security 13 improvements in the Internet. The goal has been to ensure that 14 communications are protected against outside observers and attackers. 16 This memo suggests that the existing threat model, while important 17 and still valid, is no longer alone sufficient to cater for the 18 pressing security issues in the Internet. For instance, it is also 19 necessary to protect systems against endpoints that are compromised, 20 malicious, or whose interests simply do not align with the interests 21 of the users. While such protection is difficult, there are some 22 measures that can be taken. 24 It is particularly important to ensure that as we continue to develop 25 Internet technology, non-communications security related threats are 26 properly understood. While the consideration of these issues is 27 relatively new in the IETF, this memo provides some initial ideas 28 about potential broader threat models to consider when designing 29 protocols for the Internet or when trying to defend against pervasive 30 monitoring. Further down the road, updated threat models could 31 result in changes in RFC 3552 (guidelines for writing security 32 considerations) and RFC 7258 (pervasive monitoring), to include 33 proper consideration of non-communications security threats. It may 34 also be necessary to have dedicated guidance on how systems design 35 and architecture affects security. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on January 10, 2020. 54 Copyright Notice 56 Copyright (c) 2019 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 72 2. Improvements in Communications Security . . . . . . . . . . . 5 73 3. Issues in Security Beyond Communications Security . . . . . . 5 74 4. Impacts . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 4.1. The Role of End-to-end . . . . . . . . . . . . . . . . . 8 76 4.2. Trusted networks . . . . . . . . . . . . . . . . . . . . 10 77 4.2.1. Even closed networks can have compromised nodes . . . 11 78 4.3. Balancing Threats . . . . . . . . . . . . . . . . . . . . 12 79 5. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 6. Potential Changes in IETF Analysis of Protocols . . . . . . . 14 81 6.1. Changes in RFC 3552 . . . . . . . . . . . . . . . . . . . 14 82 6.2. Changes in RFC 7258 . . . . . . . . . . . . . . . . . . . 15 83 6.3. System and Architecture Aspects . . . . . . . . . . . . . 15 84 7. Other Work . . . . . . . . . . . . . . . . . . . . . . . . . 15 85 8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 15 86 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 87 10. Informative References . . . . . . . . . . . . . . . . . . . 16 88 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 90 1. Introduction 92 Communications security has been at the center of many security 93 improvements in the Internet. The goal has been to ensure that 94 communications are protected against outside observers and attackers. 95 At the IETF, this approach has been formalized in BCP 72 [RFC3552], 96 which defined the Internet threat model in 2003. 98 The purpose of a threat model is to outline what threats exist in 99 order to assist the protocol designer. But RFC 3552 also ruled some 100 threats to be in scope and of primary interest, and some threats out 101 of scope [RFC3552]: 103 The Internet environment has a fairly well understood threat 104 model. In general, we assume that the end-systems engaging in a 105 protocol exchange have not themselves been compromised. 106 Protecting against an attack when one of the end-systems has been 107 compromised is extraordinarily difficult. It is, however, 108 possible to design protocols which minimize the extent of the 109 damage done under these circumstances. 111 By contrast, we assume that the attacker has nearly complete 112 control of the communications channel over which the end-systems 113 communicate. This means that the attacker can read any PDU 114 (Protocol Data Unit) on the network and undetectably remove, 115 change, or inject forged packets onto the wire. 117 However, the communications-security -only threat model is becoming 118 outdated. This is due to three factors: 120 o Advances in protecting most of our communications with strong 121 cryptographic means. This has resulted in much improved 122 communications security, but also highlights the need for 123 addressing other, remaining issues. This is not to say that 124 communications security is not important, it still is: 125 improvements are still needed. Not all communications have been 126 protected, and even out of the already protected communications, 127 not all of their aspects have been fully protected. Fortunately, 128 there are ongoing projects working on improvements. 130 o Adversaries have increased their pressure against other avenues of 131 attack, from compromising devices to legal coercion of centralized 132 endpoints in conversations. 134 o New adversaries and risks have arisen, e.g., due to creation of 135 large centralized information sources. 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 consent of the users. 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 issues in the Internet. For instance, while it 146 continues to be very important to protect Internet communications 147 against outsiders, it is also necessary to protect systems against 148 endpoints that are compromised, malicious, or whose interests simply 149 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 affects 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 be 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 The rest of this memo is organized as follows. Section 2 and 182 Section 3 outline the situation with respect to communications 183 security and beyond it. Section 4.1 discusses how the author 184 believes the Internet threat model should evolve, and what types of 185 threats should be seen as critical ones and in-scope. Section 5 will 186 also discuss high-level guidance to addressing these threats. 188 Section 6 outlines the author's suggested future changes to RFC 3552 189 and RFC 7258 and the need for guidance on the impacts of system 190 design and architecture on security. Comments are solicited on these 191 and other aspects of this document. The best place for discussion is 192 on the arch-discuss list (https://www.ietf.org/mailman/listinfo/ 193 Architecture-discuss). This memo acts also as an input for the IAB 194 retreat discussion on threat models, and it is a submission for the 195 IAB DEDR workshop (https://www.iab.org/activities/workshops/dedr- 196 workshop/). 198 Finally, Section 7 highlights other discussions in this problem space 199 and Section 8 draws some conclusions for next steps. 201 2. Improvements in Communications Security 203 The fraction of Internet traffic that is cryptographically protected 204 has grown tremendously in the last few years. Several factors have 205 contributed to this change, from Snowden revelations to business 206 reasons and to better available technology such as HTTP/2 [RFC7540], 207 TLS 1.3 [RFC8446], QUIC [I-D.ietf-quic-transport]. 209 In many networks, the majority of traffic has flipped from being 210 cleartext to being encrypted. Reaching the level of (almost) all 211 traffic being encrypted is no longer something unthinkable but rather 212 a likely outcome in a few years. 214 At the same time, technology developments and policy choices have 215 driven the scope of cryptographic protection from protecting only the 216 pure payload to protecting much of the rest as well, including far 217 more header and meta-data information than was protected before. For 218 instance, efforts are ongoing in the IETF to assist encrypting 219 transport headers [I-D.ietf-quic-transport], server domain name 220 information in TLS [I-D.ietf-tls-esni], and domain name queries 221 [RFC8484]. 223 There has also been improvements to ensure that the security 224 protocols that are in use actually have suitable credentials and that 225 those credentials have not been compromised, see, for instance, Let's 226 Encrypt [RFC8555], HSTS [RFC6797], HPKP [RFC7469], and Expect-CT 227 [I-D.ietf-httpbis-expect-ct]. 229 This is not to say that all problems in communications security have 230 been resolved - far from it. But the situation is definitely 231 different from what it was a few years ago. Remaining issues will be 232 and are worked on; the fight between defense and attack will also 233 continue. Communications security will stay at the top of the agenda 234 in any Internet technology development. 236 3. Issues in Security Beyond Communications Security 238 There are, however, significant issues beyond communications security 239 in the Internet. To begin with, it is not necessarily clear that one 240 can trust all the endpoints. 242 Of course, the endpoints were never trusted, but the pressures 243 against endpoints issues seem to be mounting. For instance, the 244 users may not be in as much control over their own devices as they 245 used to be due to manufacturer-controlled operating system 246 installations and locked device ecosystems. And within those 247 ecosystems, even the applications that are available tend to have 248 features that users by themselves would most likely not desire to 249 have, such as excessive rights to media, location, and peripherals. 250 There are also designated efforts by various authorities to hack end- 251 user devices as a means of intercepting data about the user. 253 The situation is different, but not necessarily better on the side of 254 servers. The pattern of communications in today's Internet is almost 255 always via a third party that has at least as much information than 256 the other parties have. For instance, these third parties are 257 typically endpoints for any transport layer security connections, and 258 able to see any communications or other messaging in cleartextx. 259 There are some exceptions, of course, e.g., messaging applications 260 with end-to-end protection. 262 With the growth of trading users' information by many of these third 263 parties, it becomes necessary to take precautions against endpoints 264 that are compromised, malicious, or whose interests simply do not 265 align with the interests of the users. 267 Specifically, the following issues need attention: 269 o Security of users' devices and the ability of the user to control 270 their own equipment. 272 o Leaks and attacks related to data at rest. 274 o Coercion of some endpoints to reveal information to authorities or 275 surveillance organizations, sometimes even in an extra-territorial 276 fashion. 278 o Application design patterns that result in cleartext information 279 passing through a third party or the application owner. 281 o Involvement of entities that have no direct need for involvement 282 for the sake of providing the service that the user is after. 284 o Network and application architectures that result in a lot of 285 information collected in a (logically) central location. 287 o Leverage and control points outside the hands of the users or end- 288 user device owners. 290 For instance, while e-mail transport security [RFC7817] has become 291 much more widely distributed in recent years, progress in securing 292 e-mail messages between users has been much slower. This has lead to 293 a situation where e-mail content is considered a critical resource by 294 mail providers who use it for machine learning, advertisement 295 targeting, and other purposes. 297 The Domain Name System (DNS) shows signs of ageing but due to the 298 legacy of deployed systems, has changed very slowly. Newer 299 technology [RFC8484] developed at the IETF enables DNS queries to be 300 performed confidentially, but its deployment is happening mostly in 301 browsers that use global DNS resolver services, such as Cloudflare's 302 1.1.1.1 or Google's 8.8.8.8. This results in faster evolution and 303 better security for end users. 305 However, if one steps back and considers the overall security effects 306 of these developments, the resulting effects can be different. While 307 the security of the actual protocol exchanges improves with the 308 introduction of this new technology, at the same time this implies a 309 move from using a worldwide distributed set of DNS resolvers into 310 more centralised global resolvers. While these resolvers are very 311 well maintained (and a great service), they are potential high-value 312 targets for pervasive monitoring and Denial-of-Service (DoS) attacks. 313 In 2016, for example, DoS attacks were launched against Dyn, one of 314 the largest DNS providers, leading to some outages. It is difficult 315 to imagine that DNS resolvers wouldn't be a target in many future 316 attacks or pervasive monitoring projects. 318 Unfortunately, there is little that even large service providers can 319 do to refuse authority-sanctioned pervasive monitoring. As a result 320 it seems that the only reasonable course of defense is to ensure that 321 no such information or control point exists. 323 There are other examples about the perils of centralised solutions in 324 Internet infrastructure. The DNS example involved an interesting 325 combination of information flows (who is asking for what domain 326 names) as well as a potential ability to exert control (what domains 327 will actually resolve to an address). Routing systems are primarily 328 about control. While there are intra-domain centralized routing 329 solutions (such as PCE [RFC4655]), a control within a single 330 administrative domain is usually not the kind of centralization that 331 we would be worried about. Global centralization would be much more 332 concerning. Fortunately, global Internet routing is performed a 333 among peers. However, controls could be introduced even in this 334 global, distributed system. To secure some of the control exchanges, 335 the Resource Public Key Infrastructure (RPKI) system ([RFC6480]) 336 allows selected Certification Authorities (CAs) to help drive 337 decisions about which participants in the routing infrastructure can 338 make what claims. If this system were globally centralized, it would 339 be a concern, but again, fortunately, current designs involve at 340 least regional distribution. 342 In general, many recent attacks relate more to information than 343 communications. For instance, personal information leaks typically 344 happen via information stored on a compromised server rather than 345 capturing communications. There is little hope that such attacks can 346 be prevented entirely. Again, the best course of action seems to be 347 avoid the disclosure of information in the first place, or at least 348 to not perform that in a manner that makes it possible that others 349 can readily use the information. 351 4. Impacts 353 4.1. The Role of End-to-end 355 [RFC1958] notes that "end-to-end functions can best be realised by 356 end-to-end protocols": 358 The basic argument is that, as a first principle, certain required 359 end-to-end functions can only be performed correctly by the end- 360 systems themselves. A specific case is that any network, however 361 carefully designed, will be subject to failures of transmission at 362 some statistically determined rate. The best way to cope with 363 this is to accept it, and give responsibility for the integrity of 364 communication to the end systems. Another specific case is end- 365 to-end security. 367 The "end-to-end argument" was originally described by Saltzer et al 368 [Saltzer]. They said: 370 The function in question can completely and correctly be 371 implemented only with the knowledge and help of the application 372 standing at the endpoints of the communication system. Therefore, 373 providing that questioned function as a feature of the 374 communication system itself is not possible. 376 These functional arguments align with other, practical arguments 377 about the evolution of the Internet under the end-to-end model. The 378 endpoints evolve quickly, often with simply having one party change 379 the necessary software on both ends. Whereas waiting for network 380 upgrades would involve potentially a large number of parties from 381 application owners to multiple network operators. 383 The end-to-end model supports permissionless innovation where new 384 innovation can flourish in the Internet without excessive wait for 385 other parties to act. 387 But the details matter. What is considered an endpoint? What 388 characteristics of Internet are we trying to optimize? This memo 389 makes the argument that, for security purposes, there is a 390 significant distinction between actual endpoints from a user's 391 interaction perspective (e.g., another user) and from a system 392 perspective (e.g., a third party relaying a message). 394 This memo proposes to focus on the distinction between "real ends" 395 and other endpoints to guide the development of protocols. A 396 conversation between one "real end" to another "real end" has 397 necessarily different security needs than a conversation between, 398 say, one of the "real ends" and a component in a larger system. The 399 end-to-end argument is used primarily for the design of one protocol. 400 The security of the system, however, depends on the entire system and 401 potentially multiple storage, compute, and communication protocol 402 aspects. All have to work properly together to obtain security. 404 For instance, a transport connection between two components of a 405 system is not an end-to-end connection even if it encompasses all the 406 protocol layers up to the application layer. It is not end-to-end, 407 if the information or control function it carries actually extends 408 beyond those components. For instance, just because an e-mail server 409 can read the contents of an e-mail message does not make it a 410 legitimate recipient of the e-mail. 412 This memo also proposes to focus on the "need to know" aspect in 413 systems. Information should not be disclosed, stored, or routed in 414 cleartext through parties that do not absolutely need to have that 415 information. 417 The proposed argument about real ends is as follows: 419 Application functions are best realised by the entities directly 420 serving the users, and when more than one entity is involved, by 421 end-to-end protocols. The role and authority of any additional 422 entities necessary to carry out a function should match their part 423 of the function. No information or control roles should be 424 provided to these additional entities unless it is required by the 425 function they provide. 427 For instance, a particular piece of information may be necessary for 428 the other real endpoint, such as message contents for another user. 429 The same piece of information may not be necessary for any additional 430 parties, unless the information had to do with, say, routing 431 information for the message to reach the other user. When 432 information is only needed by the actual other endpoint, it should be 433 protected and be only relayed to the actual other endpoint. Protocol 434 design should ensure that the additional parties do not have access 435 to the information. 437 Note that it may well be that the easiest design approach is to send 438 all information to a third party and have majority of actual 439 functionality reside in that third party. But this is a case of a 440 clear tradeoff between ease of change by evolving that third party 441 vs. providing reasonable security against misuse of information. 443 Note that the above "real ends" argument is not limited to 444 communication systems. Even an application that does not communicate 445 with anyone else than its user may be implemented on top of a 446 distributed system where some information about the user is exposed 447 to untrusted parties. 449 The implications of the system security also extend beyond 450 information and control aspects. For instance, poorly design 451 component protocols can become DoS vectors which are then used to 452 attack other parts of the system. Availability is an important 453 aspect to consider in the analysis along other aspects. 455 4.2. Trusted networks 457 Some systems are thought of as being deployed only in a closed 458 setting, where all the relevant nodes are under direct control of the 459 network administrators. Technologies developed for such networks 460 tend to be optimized, at least initially, for these environments, and 461 may lack security features necessary for different types of 462 deployments. 464 It is well known that many such systems evolve over time, grow, and 465 get used and connected in new ways. For instance, the collaboration 466 and mergers between organizations, and new services for customers may 467 change the system or its environment. A system that used to be truly 468 within an administrative domain may suddenly need to cross network 469 boundaries or even run over the Internet. As a result, it is also 470 well known that it is good to ensure that underlying technologies 471 used in such systems can cope with that evolution, for instance, by 472 having the necessary security capabilities to operate in different 473 environments. 475 In general, the outside vs. inside security model is outdated for 476 most situations, due to the complex and evolving networks and the 477 need to support mixture of devices from different sources (e.g., BYOD 478 networks). Network virtualization also implies that previously clear 479 notions of local area networks and physical proximity may create an 480 entirely different reality from what appears from a simple notion of 481 a local network. 483 4.2.1. Even closed networks can have compromised nodes 485 This memo argues that the situation is even more dire than what was 486 explained above. It is impossible to ensure that all components in a 487 network are actually trusted. Even in a closed network with 488 carefully managed components there may be compromised components, and 489 this should be factored into the design of the system and protocols 490 used in the system. 492 For instance, during the Snowden revelations it was reported that 493 internal communication flows of large content providers were 494 compromised in an effort to acquire information from large number of 495 end users. This shows the need to protect not just communications 496 targeted to go over the Internet, but in many cases also internal and 497 control communications. 499 Furthermore, there is a danger of compromised nodes, so 500 communications security alone will be insufficient to protect against 501 this. The defences against this include limiting information within 502 networks to the parties that have a need to know, as well as limiting 503 control capabilities. This is necessary even when all the nodes are 504 under the control of the same network manager; the network manager 505 needs to assume that some nodes and communications will be 506 compromised, and build a system to mitigate or minimise attacks even 507 under that assumption. 509 Even airgapped networks can have these issues, as evidenced, for 510 instance, by the Stuxnet worm. The Internet is not the only form of 511 connectivity, as most systems include, for instance, USB ports that 512 proved to be the achilles heel of the targets in the Stuxnet case. 513 More commonly, every system runs large amount of software, and it is 514 often not practical or even possible to black the software to prevent 515 compromised code even in a high-security setting, let alone in 516 commercial or private networks. Installation media, physical ports, 517 both open source and proprietary programs, firmware, or even 518 innocent-looking components on a circuit board can be suspect. In 519 addition, complex underlying computing platforms, such as modern CPUs 520 with underlying security and management tools are prone for problems. 522 In general, this means that one cannot entirely trust even a closed 523 system where you picked all the components yourself. Analysis for 524 the security of many interesting real-world systems now commonly 525 needs to include cross-component attacks, e.g., the use of car radios 526 and other externally communicating devices as part of attacks 527 launched against the control components such as breaks in a car 528 [Savage]. 530 4.3. Balancing Threats 532 Note that not all information needs to be protected, and not all 533 threats can be protected against. But it is important that the main 534 threats are understood and protected against. 536 Sometimes there are higher-level mechanisms that provide safeguards 537 for failures. For instance, it is very difficult in general to 538 protect against denial-of-service against compromised nodes on a 539 communications path. However, it may be possible to detect that a 540 service has failed. 542 Another example is from packet-carrying networks. Payload traffic 543 that has been properly protected with encryption does not provide 544 much value to an attacker. As a result, it does not always make 545 sense, for instance, encrypt every packet transmission in a packet- 546 carrying system where the traffic is already encrypted at other 547 layers. But it almost always makes sense to protect control 548 communications and to understand the impacts of compromised nodes, 549 particularly control nodes. 551 5. Guidelines 553 As [RFC3935] says: 555 We embrace technical concepts such as decentralized control, edge- 556 user empowerment and sharing of resources, because those concepts 557 resonate with the core values of the IETF community. 559 To be more specific, this memo suggests the following guidelines for 560 protocol designers: 562 1. Consider first principles in protecting information and systems, 563 rather than following a specific pattern such as protecting 564 information in a particular way or at a particular protocol 565 layer. It is necessary to understand what components can be 566 compromised, where interests may or may not be aligned, and what 567 parties have a legitimate role in being a party to a specific 568 information or a control task. 570 2. Minimize information passed to others: Information passed to 571 another party in a protocol exchange should be minimized to guard 572 against the potential compromise of that party. 574 3. Perform end-to-end protection via other parties: Information 575 passed via another party who does not intrinsically need the 576 information to perform its function should be protected end-to- 577 end to its intended recipient. This guideline is general, and 578 holds equally for sending TCP/IP packets, TLS connections, or 579 application-layer interactions. As [I-D.iab-wire-image] notes, 580 it is a useful design rule to avoid "accidental invariance" (the 581 deployment of on-path devices that over-time start to make 582 assumptions about protocols). However, it is also a necessary 583 security design rule to avoid "accidental disclosure" where 584 information originally thought to be benign and untapped over- 585 time becomes a significant information leak. This guideline can 586 also be applied for different aspects of security, e.g., 587 confidentiality and integrity protection, depending on what the 588 specific need for information is in the other parties. 590 4. Minimize passing of control functions to others: Any passing of 591 control functions to other parties should be minimized to guard 592 against the potential misuse of those control functions. This 593 applies to both technical (e.g., nodes that assign resources) and 594 process control functions (e.g., the ability to allocate number 595 or develop extensions). Control functions can also become a 596 matter of contest and power struggle, even in cases where their 597 function as such is minimal, as we saw with the IANA transition 598 debates. 600 5. Avoid centralized resources: While centralized components, 601 resources, and function provide usually a useful function, there 602 are grave issues associated with them. Protocol and network 603 design should balance the benefits of centralized resources or 604 control points against the threats arising from them. The 605 general guideline is to avoid such centralized resources when 606 possible. And if it is not possible, find a way to allow the 607 centralized resources to be selectable, depending on context and 608 user settings. 610 6. Have explicit agreements: When users and their devices provide 611 information to network entities, it would be beneficial to have 612 an opportunity for the users to state their requirements 613 regarding the use of the information provided in this way. While 614 the actual use of such requirements and the willingness of 615 network entities to agree to them remains to be seen, at the 616 moment even the technical means of doing this are limited. For 617 instance, it would be beneficial to be able to embed usage 618 requirements within popular data formats. 620 7. Treat parties that your equipment connects to with suspicion, 621 even if the communications are encrypted. The other endpoint may 622 misuse any information or control opportunity in the 623 communication. Similarly, even parties within your own system 624 need to be treated with suspicision, as some nodes may become 625 compromised. 627 8. Do not take any of this as blanket reason to provide no 628 information to anyone, encrypt everything to everyone, or other 629 extreme measures. However, the designers of a system need to be 630 aware of the different threats facing their system, and deal with 631 the most serious ones (of which there are typically many). 632 Similarly, users should be aware of the choices made in a 633 particular design, and avoid designs or products that protect 634 against some threats but are wide open to other serious issues. 636 6. Potential Changes in IETF Analysis of Protocols 638 6.1. Changes in RFC 3552 640 This memo suggests that changes maybe necessary in RFC 3552. One 641 initial, draft proposal for such changes would be this: 643 OLD: 645 In general, we assume that the end-systems engaging in a protocol 646 exchange have not themselves been compromised. Protecting against 647 an attack when one of the end-systems has been compromised is 648 extraordinarily difficult. It is, however, possible to design 649 protocols which minimize the extent of the damage done under these 650 circumstances. 652 NEW: 654 In general, we assume that the end-system engaging in a protocol 655 exchange has not itself been compromised. Protecting against an 656 attack of a protocol implementation itself is extraordinarily 657 difficult. It is, however, possible to design protocols which 658 minimize the extent of the damage done when the other parties in a 659 protocol become compromised or do not act in the best interests 660 the end-system implementing a protocol. 662 In addition, the following new section could be added to discuss the 663 capabilities required to mount an attack: 665 NEW: 667 3.x. Other endpoint compromise 669 In this attack, the other endpoints in the protocol become 670 compromised. As a result, they can, for instance, misuse any 671 information that the end-system implementing a protocol has sent 672 to the compromised endpoint. 674 6.2. Changes in RFC 7258 676 This memo also suggests that additional guidelines may be necessary 677 in RFC 7258. An initial, draft suggestion for starting point of 678 those changes could be adding the following paragraph after the 2nd 679 paragraph in Section 2: 681 NEW: 683 PM attacks include those cases where information collected by a 684 legitimate protocol participant is misused for PM purposes. The 685 attacks also include those cases where a protocol or network 686 architecture results in centralized data storage or control 687 functions relating to many users, raising the risk of said misuse. 689 6.3. System and Architecture Aspects 691 This definitely needs more attention from Internet technology 692 developers and standards organizations. Here is one possible 694 The design of any Internet technology should start from an 695 understanding of the participants in a system, their roles, and 696 the extent to which they should have access to information and 697 ability to control other participants. 699 7. Other Work 701 See, for instance, [I-D.farrell-etm]. 703 8. Conclusions 705 More work is needed in this area. To start with, Internet technology 706 developers need to be better aware of the issues beyond 707 communications security, and consider them in design. At the IETF it 708 would be beneficial to include some of these considerations in the 709 usual systematic security analysis of technologies under development. 711 In particular, when the IETF develops infrastructure technology for 712 the Internet (such as routing or naming systems), considering the 713 impacts of data generated by those technologies is important. 714 Minimising data collection from users, minimising the parties who get 715 exposed to user data, and protecting data that is relayed or stored 716 in systems should be a priority. 718 A key focus area at the IETF has been the security of transport 719 protocols, and how transport layer security can be best used to 720 provide the right security for various applications. However, more 721 work is needed in equivalently broadly deployed tools for minimising 722 or obfuscating information provided by users to other entities, and 723 the use of end-to-end security through entities that are involved in 724 the protocol exchange but who do not need to know everything that is 725 being passed through them. 727 Comments on the issues discussed in this memo are gladly taken either 728 privately or on the architecture-discuss mailing list. 730 9. Acknowledgements 732 The author would like to thank John Mattsson, Mirja Kuehlewind, 733 Alissa Cooper, Stephen Farrell, Eric Rescorla, Simone Ferlin, 734 Kathleen Moriarty, Brian Trammell, Mark Nottingham, Christian 735 Huitema, Karl Norrman, Ted Hardie, Mohit Sethi, Phillip Hallam-Baker, 736 Goran Eriksson and the IAB for interesting discussions in this 737 problem space. The author would also like to thank all members of 738 the 2019 Design Expectations vs. Deployment Reality (DEDR) IAB 739 workshop held in Kirkkonummi, Finland. 741 10. Informative References 743 [I-D.farrell-etm] 744 Farrell, S., "We're gonna need a bigger threat model", 745 draft-farrell-etm-03 (work in progress), July 2019. 747 [I-D.iab-wire-image] 748 Trammell, B. and M. Kuehlewind, "The Wire Image of a 749 Network Protocol", draft-iab-wire-image-01 (work in 750 progress), November 2018. 752 [I-D.ietf-httpbis-expect-ct] 753 estark@google.com, e., "Expect-CT Extension for HTTP", 754 draft-ietf-httpbis-expect-ct-08 (work in progress), 755 December 2018. 757 [I-D.ietf-quic-transport] 758 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 759 and Secure Transport", draft-ietf-quic-transport-20 (work 760 in progress), April 2019. 762 [I-D.ietf-tls-esni] 763 Rescorla, E., Oku, K., Sullivan, N., and C. Wood, 764 "Encrypted Server Name Indication for TLS 1.3", draft- 765 ietf-tls-esni-03 (work in progress), March 2019. 767 [I-D.nottingham-for-the-users] 768 Nottingham, M., "The Internet is for End Users", draft- 769 nottingham-for-the-users-08 (work in progress), June 2019. 771 [RFC1958] Carpenter, B., Ed., "Architectural Principles of the 772 Internet", RFC 1958, DOI 10.17487/RFC1958, June 1996, 773 . 775 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 776 Text on Security Considerations", BCP 72, RFC 3552, 777 DOI 10.17487/RFC3552, July 2003, . 780 [RFC3935] Alvestrand, H., "A Mission Statement for the IETF", 781 BCP 95, RFC 3935, DOI 10.17487/RFC3935, October 2004, 782 . 784 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 785 Element (PCE)-Based Architecture", RFC 4655, 786 DOI 10.17487/RFC4655, August 2006, . 789 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 790 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 791 February 2012, . 793 [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict 794 Transport Security (HSTS)", RFC 6797, 795 DOI 10.17487/RFC6797, November 2012, . 798 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 799 Morris, J., Hansen, M., and R. Smith, "Privacy 800 Considerations for Internet Protocols", RFC 6973, 801 DOI 10.17487/RFC6973, July 2013, . 804 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 805 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 806 2014, . 808 [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning 809 Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 810 2015, . 812 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 813 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 814 DOI 10.17487/RFC7540, May 2015, . 817 [RFC7817] Melnikov, A., "Updated Transport Layer Security (TLS) 818 Server Identity Check Procedure for Email-Related 819 Protocols", RFC 7817, DOI 10.17487/RFC7817, March 2016, 820 . 822 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 823 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 824 . 826 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 827 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 828 . 830 [RFC8546] Trammell, B. and M. Kuehlewind, "The Wire Image of a 831 Network Protocol", RFC 8546, DOI 10.17487/RFC8546, April 832 2019, . 834 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 835 Kasten, "Automatic Certificate Management Environment 836 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 837 . 839 [Saltzer] Saltzer, J., Reed, D., and D. Clark, "End-To-End Arguments 840 in System Design", ACM TOCS, Vol 2, Number 4, pp 277-288 , 841 November 1984. 843 [Savage] Savage, S., "Modern Automotive Vulnerabilities: Causes, 844 Disclosures, and Outcomes", USENIX , 2016. 846 Author's Address 848 Jari Arkko 849 Ericsson 851 Email: jari.arkko@piuha.net