idnits 2.17.1 draft-arkko-arch-internet-threat-model-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 : ---------------------------------------------------------------------------- ** 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 (April 30, 2019) is 1824 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 639, but no explicit reference was found in the text == Unused Reference: 'RFC6973' is defined on line 671, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-farrell-etm-00 == 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-07 -- Obsolete informational reference (is this intentional?): RFC 7540 (Obsoleted by RFC 9113) Summary: 1 error (**), 0 flaws (~~), 8 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 April 30, 2019 5 Expires: November 1, 2019 7 Changes in the Internet Threat Model 8 draft-arkko-arch-internet-threat-model-00 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 https://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 November 1, 2019. 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 (https://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. The Role of End-to-end . . . . . . . . . . . . . . . . . . . 8 75 4.1. Guidelines . . . . . . . . . . . . . . . . . . . . . . . 10 76 5. Potential Changes in IETF Analysis of Protocols . . . . . . . 11 77 5.1. Changes in RFC 3552 . . . . . . . . . . . . . . . . . . . 11 78 5.2. Changes in RFC 7258 . . . . . . . . . . . . . . . . . . . 12 79 5.3. System and Architecture Aspects . . . . . . . . . . . . . 12 80 6. Other Work . . . . . . . . . . . . . . . . . . . . . . . . . 13 81 7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 13 82 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 83 9. Informative References . . . . . . . . . . . . . . . . . . . 13 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 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. This is due to three factors: 116 o Advances in protecting most of our communications with strong 117 cryptographic means. This has resulted in much improved 118 communications security, but also higlights 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 compromising devices to legal coercion of centralized 128 endpoints in conversations. 130 o New adversaries and risks have arisen, e.g., due to creation of 131 large centralized information sources. 133 In short, attacks are migrating towards the currently easier targets, 134 which no longer necessarily include direct attacks on traffic flows. 135 In addition, trading information about users and ability to influence 136 them has become a common practice for many Internet services, often 137 without consent of the users. 139 This memo suggests that the existing threat model, while important 140 and still valid, is no longer alone sufficient to cater for the 141 pressing security issues in the Internet. For instance, while it 142 continues to be very important to protect Internet communications 143 against outsiders, it is also necessary to protect systems against 144 endpoints that are compromised, malicious, or whose interests simply 145 do not align with the interests of the users. 147 Of course, there are many trade-offs in the Internet on who one 148 chooses to interact with and why or how. It is not the role of this 149 memo to dictate those choices. But it is important that we 150 understand the implications of different practices. It is also 151 important that when it comes to basic Internet infrastructure, our 152 chosen technologies lead to minimal exposure with respect to the non- 153 communications threats. 155 It is particularly important to ensure that non-communications 156 security related threats are properly understood for any new Internet 157 technology. While the consideration of these issues is relatively 158 new in the IETF, this memo provides some initial ideas about 159 potential broader threat models to consider when designing protocols 160 for the Internet or when trying to defend against pervasive 161 monitoring. Further down the road, updated threat models could 162 result in changes in BCP 72 [RFC3552] (guidelines for writing 163 security considerations) and BCP 188 [RFC7258] (pervasive 164 monitoring), to include proper consideration of non-communications 165 security threats. 167 It may also be necessary to have dedicated guidance on how systems 168 design and architecture affects security. The sole consideration of 169 communications security aspects in designing Internet protocols may 170 lead to accidental or increased impact of security issues elsewhere. 171 For instance, allowing a participant to unnecessarily collect or 172 receive information may be lead to a similar effect as described in 173 [RFC8546] for protocols: over time, unnecessary information will get 174 used with all the associated downsides, regardless of what deployment 175 expectations there were during protocol design. 177 The rest of this memo is organized as follows. Section 2 and 178 Section 3 outline the situation with respect to communications 179 security and beyond it. Section 4 discusses how the author believes 180 the Internet threat model should evolve, and what types of threats 181 should be seen as critical ones and in-scope. Section 4.1 will also 182 discuss high-level guidance to addressing these threats. 184 Section 5 outlines the author's suggested future changes to RFC 3552 185 and RFC 7258 and the need for guidance on the impacts of system 186 design and architecture on security. Comments are solicited on these 187 and other aspects of this document. The best place for discussion is 188 on the arch-discuss list (https://www.ietf.org/mailman/listinfo/ 189 Architecture-discuss). This memo acts also as an input for the IAB 190 retreat discussion on threat models, and it is a submission for the 191 IAB DEDR workshop (https://www.iab.org/activities/workshops/dedr- 192 workshop/). 194 Finally, Section 6 highlights other discussions in this problem space 195 and Section 7 draws some conclusions for next steps. 197 2. Improvements in Communications Security 199 The fraction of Internet traffic that is cryptographically protected 200 has grown tremendously in the last few years. Several factors have 201 contributed to this change, from Snowden revelations to business 202 reasons and to better available technology such as HTTP/2 [RFC7540], 203 TLS 1.3 [RFC8446], QUIC [I-D.ietf-quic-transport]. 205 In many networks, the majority of traffic has flipped from being 206 cleartext to being encrypted. Reaching the level of (almost) all 207 traffic being encrypted is no longer something unthinkable but rather 208 a likely outcome in a few years. 210 At the same time, technology developments and policy choices have 211 driven the scope of cryptographic protection from protecting only the 212 pure payload to protecting much of the rest as well, including far 213 more header and meta-data information than was protected before. For 214 instance, efforts are ongoing in the IETF to assist encrypting 215 transport headers [I-D.ietf-quic-transport], server domain name 216 information in TLS [I-D.ietf-tls-esni], and domain name queries 217 [RFC8484]. 219 There has also been improvements to ensure that the security 220 protocols that are in use actually have suitable credentials and that 221 those credentials have not been compromised, see, for instance, Let's 222 Encrypt [RFC8555], HSTS [RFC6797], HPKP [RFC7469], and Expect-CT 223 [I-D.ietf-httpbis-expect-ct]. 225 This is not to say that all problems in communications security have 226 been resolved - far from it. But the situation is definitely 227 different from what it was a few years ago. Remaining issues will be 228 and are worked on; the fight between defense and attack will also 229 continue. Communications security will stay at the top of the agenda 230 in any Internet technology development. 232 3. Issues in Security Beyond Communications Security 234 There are, however, significant issues beyond communications security 235 in the Internet. To begin with, it is not necessarily clear that one 236 can trust all the endpoints. 238 Of course, the endpoints were never trusted, but the pressures 239 against endpoints issues seem to be mounting. For instance, the 240 users may not be in as much control over their own devices as they 241 used to be due to manufacturer-controlled operating system 242 installations and locked device ecosystems. And within those 243 ecosystems, even the applications that are available tend to have 244 features that users by themselves would most likely not desire to 245 have, such as excessive rights to media, location, and peripherals. 246 There are also designated efforts by various authorities to hack end- 247 user devices as a means of intercepting data about the user. 249 The situation is different, but not necessarily better on the side of 250 servers. The pattern of communications in today's Internet is almost 251 always via a third party that has at least as much information than 252 the other parties have. For instance, these third parties are 253 typically endpoints for any transport layer security connections, and 254 able to see any communications or other messaging in cleartextx. 255 There are some exceptions, of course, e.g., messaging applications 256 with end-to-end protection. 258 With the growth of trading users' information by many of these third 259 parties, it becomes necessary to take precautions against endpoints 260 that are compromised, malicious, or whose interests simply do not 261 align with the interests of the users. 263 Specifically, the following issues need attention: 265 o Security of users' devices and the ability of the user to control 266 their own equipment. 268 o Leaks and attacks related to data at rest. 270 o Coercion of some endpoints to reveal information to authorities or 271 surveillance organizations, sometimes even in an extra-territorial 272 fashion. 274 o Application design patterns that result in cleartext information 275 passing through a third party or the application owner. 277 o Involvement of entities that have no direct need for involvement 278 for the sake of providing the service that the user is after. 280 o Network and application architectures that result in a lot of 281 information collected in a (logically) central location. 283 o Leverage and control points outside the hands of the users or end- 284 user device owners. 286 For instance, while e-mail transport security [RFC7817] has become 287 much more widely distributed in recent years, progress in securing 288 e-mail messages between users has been much slower. This has lead to 289 a situation where e-mail content is considered a critical resource by 290 mail providers who use it for machine learning, advertisement 291 targeting, and other purposes. 293 The Domain Name System (DNS) shows signs of ageing but due to the 294 legacy of deployed systems, has changed very slowly. Newer 295 technology [RFC8484] developed at the IETF enables DNS queries to be 296 performed confidentially, but its deployment is happening mostly in 297 browsers that use global DNS resolver services, such as Cloudflare's 298 1.1.1.1 or Google's 8.8.8.8. This results in faster evolution and 299 better security for end users. 301 However, if one steps back and considers the overall security effects 302 of these developments, the resulting effects can be different. While 303 the security of the actual protocol exchanges improves with the 304 introduction of this new technology, at the same time this implies a 305 move from using a worldwide distributed set of DNS resolvers into 306 more centralised global resolvers. While these resolvers are very 307 well maintained (and a great service), they are potential high-value 308 targets for pervasive monitoring and Denial-of-Service (DoS) attacks. 309 In 2016, for example, DoS attacks were launched against Dyn, one of 310 the largest DNS providers, leading to some outages. It is difficult 311 to imagine that DNS resolvers wouldn't be a target in many future 312 attacks or pervasive monitoring projects. 314 Unfortunately, there is little that even large service providers can 315 do to refuse authority-sanctioned pervasive monitoring. As a result 316 it seems that the only reasonable course of defense is to ensure that 317 no such information or control point exists. 319 There are other examples about the perils of centralised solutions in 320 Internet infrastructure. The DNS example involved an interesting 321 combination of information flows (who is asking for what domain 322 names) as well as a potential ability to exert control (what domains 323 will actually resolve to an address). Routing systems are primarily 324 about control. While there are intra-domain centralized routing 325 solutions (such as PCE [RFC4655]), a control within a single 326 administrative domain is usually not the kind of centralization that 327 we would be worried about. Global centralization would be much more 328 concerning. Fortunately, global Internet routing is performed a 329 among peers. However, controls could be introduced even in this 330 global, distributed system. To secure some of the control exchanges, 331 the Resource Public Key Infrastructure (RPKI) system ([RFC6480]) 332 allows selected Certification Authorities (CAs) to help drive 333 decisions about which participants in the routing infrastructure can 334 make what claims. If this system were globally centralized, it would 335 be a concern, but again, fortunately, current designs involve at 336 least regional distribution. 338 In general, many recent attacks relate more to information than 339 communications. For instance, personal information leaks typically 340 happen via information stored on a compromised server rather than 341 capturing communications. There is little hope that such attacks can 342 be prevented entirely. Again, the best course of action seems to be 343 avoid the disclosure of information in the first place, or at least 344 to not perform that in a manner that makes it possible that others 345 can readily use the information. 347 4. The Role of End-to-end 349 [RFC1958] notes that "end-to-end functions can best be realised by 350 end-to-end protocols": 352 The basic argument is that, as a first principle, certain required 353 end-to-end functions can only be performed correctly by the end- 354 systems themselves. A specific case is that any network, however 355 carefully designed, will be subject to failures of transmission at 356 some statistically determined rate. The best way to cope with 357 this is to accept it, and give responsibility for the integrity of 358 communication to the end systems. Another specific case is end- 359 to-end security. 361 The "end-to-end argument" was originally described by Saltzer et al 362 [Saltzer]. They said: 364 The function in question can completely and correctly be 365 implemented only with the knowledge and help of the application 366 standing at the endpoints of the communication system. Therefore, 367 providing that questioned function as a feature of the 368 communication system itself is not possible. 370 These functional arguments align with other, practical arguments 371 about the evolution of the Internet under the end-to-end model. The 372 endpoints evolve quickly, often with simply having one party change 373 the necessary software on both ends. Whereas waiting for network 374 upgrades would involve potentially a large number of parties from 375 application owners to multiple network operators. 377 The end-to-end model supports permissionless innovation where new 378 innovation can flourish in the Internet without excessive wait for 379 other parties to act. 381 But the details matter. What is considered an endpoint? What 382 characteristics of Internet are we trying to optimize? This memo 383 makes the argument that, for security purposes, there is a 384 significant distinction between actual endpoints from a user's 385 interaction perspective (e.g., another user) and from a system 386 perspective (e.g., a third party relaying a message). 388 This memo proposes to focus on the distinction between "real ends" 389 and other endpoints to guide the development of protocols. A 390 conversation between one "real end" to another "real end" has 391 necessarily different security needs than a conversation between, 392 say, one of the "real ends" and a component in a larger system. The 393 end-to-end argument is used primarily for the design of one protocol. 394 The security of the system, however, depends on the entire system and 395 potentially multiple storage, compute, and communication protocol 396 aspects. All have to work properly together to obtain security. 398 For instance, a transport connection between two components of a 399 system is not an end-to-end connection even if it encompasses all the 400 protocol layers up to the application layer. It is not end-to-end, 401 if the information or control function it carries actually extends 402 beyond those components. For instance, just because an e-mail server 403 can read the contents of an e-mail message does not make it a 404 legitimate recipient of the e-mail. 406 This memo also proposes to focus on the "need to know" aspect in 407 systems. Information should not be disclosed, stored, or routed in 408 cleartext through parties that do not absolutely need to have that 409 information. 411 The proposed argument about real ends is as follows: 413 Application functions are best realised by the entities directly 414 serving the users, and when more than one entity is involved, by 415 end-to-end protocols. The role and authority of any additional 416 entities necessary to carry out a function should match their part 417 of the function. No information or control roles should be 418 provided to these additional entities unless it is required by the 419 function they provide. 421 For instance, a particular piece of information may be necessary for 422 the other real endpoint, such as message contents for another user. 423 The same piece of information may not be necessary for any additional 424 parties, unless the information had to do with, say, routing 425 information for the message to reach the other user. When 426 information is only needed by the actual other endpoint, it should be 427 protected and be only relayed to the actual other endpoint. Protocol 428 design should ensure that the additional parties do not have access 429 to the information. 431 Note that it may well be that the easiest design approach is to send 432 all information to a third party and have majority of actual 433 functionality reside in that third party. But this is a case of a 434 clear tradeoff between ease of change by evolving that third party 435 vs. providing reasonable security against misuse of information. 437 Note that the above "real ends" argument is not limited to 438 communication systems. Even an application that does not communicate 439 with anyone else than its user may be implemented on top of a 440 distributed system where some information about the user is exposed 441 to untrusted parties. 443 The implications of the system security also extend beyond 444 information and control aspects. For instance, poorly design 445 component protocols can become DoS vectors which are then used to 446 attack other parts of the system. Availability is an important 447 aspect to consider in the analysis along other aspects. 449 4.1. Guidelines 451 As [RFC3935] says: 453 We embrace technical concepts such as decentralized control, edge- 454 user empowerment and sharing of resources, because those concepts 455 resonate with the core values of the IETF community. 457 To be more specific, this memo suggests the following guidelines for 458 protocol designers: 460 1. Minimizing information passed to others: Information passed to 461 another party in a protocol exchange should be minimized to guard 462 against the potential compromise of that party. 464 2. End-to-end protection via other parties: Information passed via 465 another party who does not intrinsically need the information to 466 perform its function should be protected end-to-end to its 467 intended recipient. This guideline is general, and holds equally 468 for sending TCP/IP packets, TLS connections, or application-layer 469 interactions. As [I-D.iab-wire-image] notes, it is a useful 470 design rule to avoid "accidental invariance" (the deployment of 471 on-path devices that over-time start to make assumptions about 472 protocols). However, it is also a necessary security design rule 473 to avoid "accidental disclosure" where information originally 474 thought to be benign and untapped over-time becomes a significant 475 information leak. This guideline can also be applied for 476 different aspects of security, e.g., confidentiality and 477 integrity protection, depending on what the specific need for 478 information is in the other parties. 480 3. Minimizing passing of control functions to others: Any passing of 481 control functions to other parties should be minimized to guard 482 against the potential misuse of those control functions. This 483 applies to both technical (e.g., nodes that assign resources) and 484 process control functions (e.g., the ability to allocate number 485 or develop extensions). Control functions can also become a 486 matter of contest and power struggle, even in cases where their 487 function as such is minimal, as we saw with the IANA transition 488 debates. 490 4. Avoiding centralized resources: While centralized components, 491 resources, and function provide usually a useful function, there 492 are grave issues associated with them. Protocol and network 493 design should balance the benefits of centralized resources or 494 control points against the threats arising from them. The 495 general guideline is to avoid such centralized resources when 496 possible. And if it is not possible, find a way to allow the 497 centralized resources to be selectable, depending on context and 498 user settings. 500 5. Explicit agreements: When users and their devices provide 501 information to network entities, it would be beneficial to have 502 an opportunity for the users to state their requirements 503 regarding the use of the information provided in this way. While 504 the actual use of such requirements and the willingness of 505 network entities to agree to them remains to be seen, at the 506 moment even the technical means of doing this are limited. For 507 instance, it would be beneficial to be able to embed usage 508 requirements within popular data formats. 510 5. Potential Changes in IETF Analysis of Protocols 512 5.1. Changes in RFC 3552 514 This memo suggests that changes maybe necessary in RFC 3552. One 515 initial, draft proposal for such changes would be this: 517 OLD: 519 In general, we assume that the end-systems engaging in a protocol 520 exchange have not themselves been compromised. Protecting against 521 an attack when one of the end-systems has been compromised is 522 extraordinarily difficult. It is, however, possible to design 523 protocols which minimize the extent of the damage done under these 524 circumstances. 526 NEW: 528 In general, we assume that the end-system engaging in a protocol 529 exchange has not itself been compromised. Protecting against an 530 attack of a protocol implementation itself is extraordinarily 531 difficult. It is, however, possible to design protocols which 532 minimize the extent of the damage done when the other parties in a 533 protocol become compromised or do not act in the best interests 534 the end-system implementing a protocol. 536 In addition, the following new section could be added to discuss the 537 capabilities required to mount an attack: 539 NEW: 541 3.x. Other endpoint compromise 543 In this attack, the other endpoints in the protocol become 544 compromised. As a result, they can, for instance, misuse any 545 information that the end-system implementing a protocol has sent 546 to the compromised endpoint. 548 5.2. Changes in RFC 7258 550 This memo also suggests that additional guidelines may be necessary 551 in RFC 7258. An initial, draft suggestion for starting point of 552 those changes could be adding the following paragraph after the 2nd 553 paragraph in Section 2: 555 NEW: 557 PM attacks include those cases where information collected by a 558 legitimate protocol participant is misused for PM purposes. The 559 attacks also include those cases where a protocol or network 560 architecture results in centralized data storage or control 561 functions relating to many users, raising the risk of said misuse. 563 5.3. System and Architecture Aspects 565 This definitely needs more attention from Internet technology 566 developers and standards organizations. Here is one possible 568 The design of any Internet technology should start from an 569 understanding of the participants in a system, their roles, and 570 the extent to which they should have access to information and 571 ability to control other participants. 573 6. Other Work 575 See, for instance, [I-D.farrell-etm]. 577 7. Conclusions 579 More work is needed in this area. To start with, Internet technology 580 developers need to be better aware of the issues beyond 581 communications security, and consider them in design. At the IETF it 582 would be beneficial to include some of these considerations in the 583 usual systematic security analysis of technologies under development. 585 In particular, when the IETF develops infrastructure technology for 586 the Internet (such as routing or naming systems), considering the 587 impacts of data generated by those technologies is important. 588 Minimising data collection from users, minimising the parties who get 589 exposed to user data, and protecting data that is relayed or stored 590 in systems should be a priority. 592 A key focus area at the IETF has been the security of transport 593 protocols, and how transport layer security can be best used to 594 provide the right security for various applications. However, more 595 work is needed in equivalently broadly deployed tools for minimising 596 or obfuscating information provided by users to other entities, and 597 the use of end-to-end security through entities that are involved in 598 the protocol exchange but who do not need to know everything that is 599 being passed through them. 601 Comments on the issues discussed in this memo are gladly taken either 602 privately or on the architecture-discuss mailing list. 604 8. Acknowledgements 606 The author would like to thank John Mattsson, Mirja Kuehlewind, 607 Alissa Cooper, Stephen Farrell, Eric Rescorla, Simone Ferlin, 608 Kathleen Moriarty, Brian Trammell, Mark Nottingham, Christian 609 Huitema, Karl Norrman, Ted Hardie, Mohit Sethi, Phillip Hallam-Baker, 610 Goran Eriksson and the IAB for interesting discussions in this 611 problem space. 613 9. Informative References 615 [I-D.farrell-etm] 616 Farrell, S., "We're gonna need a bigger threat model", 617 draft-farrell-etm-00 (work in progress), April 2019. 619 [I-D.iab-wire-image] 620 Trammell, B. and M. Kuehlewind, "The Wire Image of a 621 Network Protocol", draft-iab-wire-image-01 (work in 622 progress), November 2018. 624 [I-D.ietf-httpbis-expect-ct] 625 estark@google.com, e., "Expect-CT Extension for HTTP", 626 draft-ietf-httpbis-expect-ct-08 (work in progress), 627 December 2018. 629 [I-D.ietf-quic-transport] 630 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 631 and Secure Transport", draft-ietf-quic-transport-20 (work 632 in progress), April 2019. 634 [I-D.ietf-tls-esni] 635 Rescorla, E., Oku, K., Sullivan, N., and C. Wood, 636 "Encrypted Server Name Indication for TLS 1.3", draft- 637 ietf-tls-esni-03 (work in progress), March 2019. 639 [I-D.nottingham-for-the-users] 640 Nottingham, M., "The Internet is for End Users", draft- 641 nottingham-for-the-users-07 (work in progress), March 642 2019. 644 [RFC1958] Carpenter, B., Ed., "Architectural Principles of the 645 Internet", RFC 1958, DOI 10.17487/RFC1958, June 1996, 646 . 648 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 649 Text on Security Considerations", BCP 72, RFC 3552, 650 DOI 10.17487/RFC3552, July 2003, 651 . 653 [RFC3935] Alvestrand, H., "A Mission Statement for the IETF", 654 BCP 95, RFC 3935, DOI 10.17487/RFC3935, October 2004, 655 . 657 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 658 Element (PCE)-Based Architecture", RFC 4655, 659 DOI 10.17487/RFC4655, August 2006, 660 . 662 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 663 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 664 February 2012, . 666 [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict 667 Transport Security (HSTS)", RFC 6797, 668 DOI 10.17487/RFC6797, November 2012, 669 . 671 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 672 Morris, J., Hansen, M., and R. Smith, "Privacy 673 Considerations for Internet Protocols", RFC 6973, 674 DOI 10.17487/RFC6973, July 2013, 675 . 677 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 678 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 679 2014, . 681 [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning 682 Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 683 2015, . 685 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 686 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 687 DOI 10.17487/RFC7540, May 2015, 688 . 690 [RFC7817] Melnikov, A., "Updated Transport Layer Security (TLS) 691 Server Identity Check Procedure for Email-Related 692 Protocols", RFC 7817, DOI 10.17487/RFC7817, March 2016, 693 . 695 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 696 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 697 . 699 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 700 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 701 . 703 [RFC8546] Trammell, B. and M. Kuehlewind, "The Wire Image of a 704 Network Protocol", RFC 8546, DOI 10.17487/RFC8546, April 705 2019, . 707 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 708 Kasten, "Automatic Certificate Management Environment 709 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 710 . 712 [Saltzer] Saltzer, J., Reed, D., and D. Clark, "End-To-End Arguments 713 in System Design", ACM TOCS, Vol 2, Number 4, November 714 1984, pp 277-288. , n.d.. 716 Author's Address 718 Jari Arkko 719 Ericsson 721 Email: jari.arkko@piuha.net