idnits 2.17.1 draft-mcfadden-smart-threat-changes-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 9, 2020) is 1387 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'CLESS' is mentioned on line 172, but not defined == Unused Reference: 'I-D.paine-smart-indicators-of-compromise-00' is defined on line 387, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-paine-smart-indicators-of-compromise-00 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Independent Submission M. McFadden 2 Internet Draft internet policy advisors 3 Intended status: Informational July 9, 2020 4 Expires: January 9, 2021 6 BCP72 - A Problem Statement 7 draft-mcfadden-smart-threat-changes-01.txt 9 Status of this Memo 11 This Internet-Draft is submitted in full conformance with the 12 provisions of BCP 78 and BCP 79. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as 22 reference material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 This Internet-Draft will expire on January 9, 2021. 32 Copyright Notice 34 Copyright (c) 2020 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with 42 respect to this document. Code Components extracted from this 43 document must include Simplified BSD License text as described in 44 Section 4.e of the Trust Legal Provisions and are provided without 45 warranty as described in the Simplified BSD License. 47 Abstract 49 RFC3552/BCP72 describes an Internet Threat model that has been used 50 in Internet protocol design. More than sixteen years have passed 51 since RFC3552 was written and the structure and topology of the 52 Internet has changed. With those changes comes a question: has the 53 Internet Threat Model changed? Or, is the model described in RFC3552 54 still largely accurate? This draft attempts to describe an non- 55 exhaustive list of changes in the current threat environment. It 56 finds that there are both qualitative and quantitative differences 57 from the environment described in RFC3552 and is intended as input 58 to the IAB program on the Internet threat model started in 2020. 60 Table of Contents 62 1. Introduction...................................................2 63 2. BCP72 Threat Model.............................................3 64 2.1. BCP72 Passive Attacks.....................................3 65 2.2. BCP72 Active Attacks......................................4 66 3. Changes to the Attack Landscape................................4 67 3.1. Quantifiable Changes......................................4 68 3.2. Qualitative Changes.......................................5 69 3.3. Data at Rest..............................................6 70 4. Observations...................................................7 71 5. Problem Statement..............................................8 72 6. Security Considerations........................................8 73 7. IANA Considerations............................................8 74 8. References.....................................................8 75 8.1. Normative References...........Error! Bookmark not defined. 76 8.2. Informative References....................................8 77 9. Acknowledgments................................................9 79 1. Introduction 81 [RFC3552] describes an Internet threat model. According to that RFC 82 the threat model "describes the capabilities that an attacker is 83 assumed to be able to deploy against a resource. It should contain 84 such information as the resources available to an attacker in terms 85 of information, computing capability, and control of a system." 87 In 2020, the IAB approved an IAB program on the Internet threat 88 model. One of its goals was to explore how the world has changed in 89 terms of threats experienced and how protocol endpoints are 90 implemented and deployed. During early discussions for that IAB 91 program - called model-t - a natural question was raised: has the 92 Internet Threat Model really changed? Or, is the model described in 93 RFC3552 still largely accurate? 95 The purpose of this draft is to examine the threat landscape of the 96 contemporary Internet and answer those questions. The draft can be 97 used as input into the IAB's model-t process for documenting why an 98 update to BCP72 might be needed. 100 Reconsideration of the guidelines for writing Security 101 Considerations sections of RFCs is not in scope for this memo. 103 2. BCP72 Threat Model 105 BCP72's threat model divides attacks based on the capabilities 106 required to mount the attack. In particular, it divides attacks 107 into two groups: passive attacks where an attacker has only limited, 108 or read-only, access to the network; and active attacks where the 109 attacker has the resources available to write to the network. BCP72 110 is careful not to locate the attack. The attacks can come from 111 arbitrary endpoints. It's worth noting that dividing the threat 112 model in this way also allows for the model to incorporate attacks 113 that come from resources not at endpoints. In fact, an entire 114 subsection of the BCP discusses on-path versus off-path attacks. 116 2.1. BCP72 Passive Attacks 118 BCP72 describes passive attacks as those in which an attacker "reads 119 packets off the network but does not write them." It then gives 120 some specific examples including password sniffing, attacks on 121 routing infrastructure, and unprotected wireless channels. 123 The description in BCP72 tacitly assumes that the attacker is in 124 control of a single resource. For example, the first type of 125 passive attack considered is one in which an attacker uses read-only 126 access to packets to extract otherwise private information. BCP72 127 discusses the problems encountered when packets are transported 128 without some form of transport or application layer security. 130 BCP72 also makes note of offline cryptographic attacks in which an 131 attacker has made offline copies of packets that have been read off 132 the network. The attacker then mounts a cryptographic attack on 133 those packets in order to extract confidential information from them 134 offline. 136 2.2. BCP72 Active Attacks 138 BCP72 says, "when an attack involves writing data to the network, we 139 refer to this as an active attack." In this case, the BCP discusses 140 spoofing packet replay attacks, message insertion, deletion and 141 insertion, man-in-the-middle, as well as a Denial of Service attack. 143 In each of these cases the BCP suggests either mitigations or 144 descriptions of what technologies could have been used to avoid the 145 weakness. 147 3. Changes to the Attack Landscape 149 3.1. Quantifiable Changes 151 In the period since 2003, one dramatic change is the number of 152 attacks seen. Published studies [I-D.lazanski-smart-users-internet] 153 show orders of magnitude increases in the number of devices 154 compromised, scale of privacy breach, and the number of attacks 155 taking place. Recent studies show that the vast majority of attacks 156 come from attackers using automated, distributed tools. This makes 157 a threat model that is built around the notion of a single attacker 158 inapplicable in the current Internet. It's worth noting that BCP72 159 does reference the concept of distributed denial of service (DDoS), 160 however its focus is on single attackers either on or off path. 162 Studies also show that certain well-known ports [IANA-WKP] are the 163 primary targets for this large jump in automated attacks. Ports 164 445, 22, 23, and 1433 make up 99% of the targets. 166 The growth in the attacks on Telnet [RFC854] is a reflection of 167 another development in the public Internet: the growth in numbers of 168 constrained devices. Endpoints that are not capable of supporting 169 endpoint protection software, effective encryption, or proper 170 authentication have proliferated on the public Internet. That many 171 of these devices do not have facilities for either self-protection 172 [CLESS] or protecting against becoming a threat on their own has 173 been documented in an IAB Workshop [IAB-IOT]. The greater number of 174 improperly protected devices has the potential to amplify attacks 175 that use them as sources for attacks on the rest of the Internet 176 ecosystem. 178 Since 2003, there have been a variety of studies examining the 179 growth in the number of devices connected to the Internet. At the 180 time of writing, one estimate is that the difference between the 181 number of devices connected in 2003 and 2020 is in the region of 22 182 billion. The sheer quantity of devices means that the Internet's 183 attack surface is significantly expanded. Quantitative surveys also 184 indicate that the greatest growth is in so-called enterprise IoT and 185 household automation. The security properties of these endpoints 186 are substantially different from hosts that made up the majority of 187 the Internet in 2003. [I-D.taddei.cless.smart.introduction] 189 Another important quantitative change to the structure of the 190 Internet is the consolidation of its infrastructure. While BCP72 is 191 certainly correct in its focus on the technologies and protocols 192 that can be exploited by attackers, it is hard to ignore the fact 193 that the threat landscape has been affected by the emergence of 194 consolidation. One example of this would be commercial or 195 governmental surveillance capabilities. In an environment where 196 there are a small number of very large entities that control the 197 fabric of connectivity and content, the threat landscape is affected 198 by the fact that it may be easier to exert control and implement 199 attacks on a small number of organizations. 201 3.2. Qualitative Changes 203 The Internet in 2003 had a relatively small number of types of 204 hosts. The client/server model of computing was dominant at that 205 time and endpoints were relatively homogeneous. 207 The diversity of deployment is an important part of the contemporary 208 Internet landscape. Not only is there a measurable and huge 209 increase in the number of endpoints (greatly increasing the attack 210 surface), but there is rich diversity in the capacity, connectivity, 211 purpose of those endpoints. As a result, while the number of 212 protocols may have not increased exponentially, the kinds of devices 213 that can be sources or targets of exploits has increased 214 significantly. 216 The threat landscape is also affected by the balance between 217 convenience versus protection from threats. Applications and 218 services fight for market and mind share by being the easiest to 219 adopt, install and use. Many users treat security and protection in 220 the same way that they treat personal health - they ignore it until 221 there is a serious problem and then expect the problem to be 222 mitigated quickly. 224 The class of attackers has changed as well. In 2003, advanced 225 persistent attacks hadn't yet been given that name and the estimated 226 monetary loss to attackers was estimated to be less than $1 billion 227 USD. The emergence of scripted and other automated tools has 228 changed the landscape dramatically. In 2019, one estimate of losses 229 due to network based attacks was in excess of $315 billion. This is 230 the direct result of the speed, financing and flexibility of those 231 doing the attacking. [I-D.lazanski-smart-users-internet] 233 It is true that, since BCP 72 was published there have been 234 significant improvements to communications security. This includes 235 securing the transport layer through protocols such as TLS 1.3, 236 HTTP/2 and secure SMTP. However, secure transport does not prevent 237 rogue applications from executing attacks even when secure transport 238 is in place. An example of this happens when VPNs themselves 239 examine or exploit traffic rather than do what they are advertised 240 to do. 242 Recent experience tells us that the Internet has evolved from 243 primarily supporting unidirectional, two-party data flows to 244 supporting both two-party and multi-endpoint communications. This 245 trend is especially seen in the move toward large-scale, work from 246 home models where multiparty communication is taken as a fundamental 247 use case. The implications of this evolution on the threat model 248 should be a part of any reconsideration of BCP72. 250 One of the other crucial changes to the Internet is the rise of the 251 application. Apps do everything for themselves that they can so they 252 do, for example, DoH [RFC8484], encrypt on their own and make 253 changes to the way the application interfaces with the Internet. It 254 used to be that applications simply relied on lower layers of the 255 stack for their services. This is no longer always the case and the 256 implications of this on the threat model may be that the nature and 257 platforms for attacks has significantly changed. 259 3.3. Data at Rest 261 The Internet Threat model in BCP72 primarily speaks to data being 262 transmitted, transited or received over the network. More recent 263 approaches to providing services over the Internet involve 264 intermediate nodes that may redirect, manipulate or store traffic. 265 While technologies such as exchange points may be seen to simply 266 part of the fabric between senders and receivers, the insertion of 267 content networks, caches and traffic analyzers has become 268 ubiquitous. 270 These middle boxes play an important role in content provision, 271 analysis and security in today's Internet. They were in limited use 272 when BCP72 was published. The importance of middleboxes is such 273 that, when protocols are developed that effectively route around 274 them, operators and content providers sometimes object. 276 Any contemporary Internet threat model must go beyond the threats to 277 traffic as it moves from Alice to Bob. Beyond intermediaries, the 278 more personal digital devices there are, the more difficult it is to 279 control and protect them. The threat model should also include 280 attacks that take place when the data is at rest or being 281 manipulated for operational reasons. Observations 283 If the IAB's Model T program finds that there have been both 284 quantitative and qualitative changes to the Internet threat model, 285 then perhaps it would be time to consider revising BCP72 to reflect 286 those changes. In this case the IAB should provide some initial 287 assistance to the IETF on how to proceed with the revision. Others 288 have argued that the end-to-end architecture model of the Internet 289 cannot be understood by just considering all of the protocol layers 290 up to the application layer. [I-D.arkko-arch-internet-threat-model] 291 In any case, it seems that there are significant changes in the 292 architecture and service model of the Internet. Those significant 293 changes may mean that significant changes need to be made in any 294 revision to the threat model documented in RFC4552. 296 In addition, BCP72's concentration on the communication channel 297 fails to account for two of the central developments of the Internet 298 in the last ten years: the rise of the application as the endpoint 299 and the diversity of endpoints that are publicly connected. 301 It might also be observed that there have already been limited 302 attempts to reconsider BCP72's threat model. As an example, the 303 Same-Origin Policy detailed in [RFC6454] shows how an application- 304 layer protocol can protect itself against certain kinds of attacks 305 based on the concept of origin (the determination and use of an 306 origin URI). 308 Another change is the emergence of state sponsored attacks on both 309 endpoints and infrastructure. These attacks are quite different in 310 both capability and intensity compared to the threats seen in 2003. 311 A case study of these types of attacks is explored in [I-D.draft- 312 paine-smart-indicators-of-compromise]. 314 Finally, protection from phishing attacks in the presence of certain 315 implementations of IDNA means that applications themselves are 316 implementing their own protections against certain types of attacks. 317 This is another example of how the application layer imposes 318 controls on an otherwise secure communication channel. 320 These are intended as only examples of how the landscape has 321 changed. It seems clear that many more changes exist and need to be 322 researched and documented. 324 4. Problem Statement 326 BCP72 is an accurate reflection of the security threat landscape at 327 the time which it was written. While the work of the IAB program on 328 the Internet threat model is essential, a revision to RFC3552 is in 329 the remit of the IETF. 331 BCP72 represents a too narrow view of the Internet's threat 332 landscape. An update is needed to: 334 . Reflect the diversity of endpoint deployment on the Internet; 336 . Document the impact of application-based security on the more 337 narrow communication channel model (possibly: consideration of 338 data in use in addition to data in motion); 340 . Account for data at rest as part of the model as well as data 341 in motion; 343 . Reflecting on the how the growth of the number of devices 344 connected affects the attack surface for the Internet at large; 346 . Research by the IAB and others on how a new, contemporary 347 threat model might be described and communicated to protocol 348 designers and others; and, 350 . Make constructive suggestions for an approach (or, methodology) 351 for the IETF to revise BCP72. 353 5. Security Considerations 355 This document is entirely about security on the Internet and is 356 intended as input into the IAB's Model T work. 358 6. IANA Considerations 360 The memo has no actions for IANA. 362 7. References 364 7.1. Informative References 366 [RFC854] Postel, J., Reynolds, J., "Telnet Protocol Specification," 367 RFC854, https://tools.ietf.org/html/rfc854 369 [RFC3552] Rescorla E., Korver, B., IAB, "Guidelines for Writing RFC 370 Text on Security Considerations," BCP 72, RFC 3552, 371 https://tools.ietf.org/html/rfc3552 373 [RFC6454] Barth, A., "The Web Origin Concept," ISSN: 2070-1721, RFC 374 6454, https://tools.ietf.org/html/rfc6454 376 [RFC8484] Hoffman, P., McManus, P., "DNS Queries over HTTPS (DoH)," 377 ISSN: 2070-1721, RFC 8484, https://tools.ietf.org/html/rfc8484 379 [I-D.arkko-arch-internet-threat-model] Arkko, J., "Changes in the 380 Internet Threat Model", draft-arkko-arch-internet-threat-model-01 381 (work in progress), July 2019. 383 [I-D.lazanski-smart-users-internet] Lazanski, D., "An Internet for 384 Users Again", draft-lazanski-smart-users-internet-00 (work in 385 progress), July 2019. 387 [I-D.paine-smart-indicators-of-compromise-00] Kaine, K., Whitehouse, 388 O., "Indicators of Compromise and Their R?le in Attack Defense," 389 https://tools.ietf.org/html/draft-paine-smart-indicators-of- 390 compromise-00 March 2020. 392 [IAB-IOT] Jimenez, J., Tschofenig, H., Thaler, D., "Report from the 393 Internet of Things (IoT) Semantic Interoperability (IOTSI) Workshop 394 2016," https://tools.ietf.org/html/draft-iab-iotsi-workshop-02 (work 395 in progress), July 2018. 397 [IANA-WKP] "Service Name and Transport Protocol Port Number 398 Registry," https://www.iana.org/assignments/service-names-port- 399 numbers/service-names-port-numbers.xhtml 401 8. Acknowledgments 403 This document was prepared using 2-Word-v2.0.template.dot. 405 Authors' Addresses 407 Mark McFadden 408 Internet policy advisors llc 409 513 Elmside Blvd 410 Madison WI 53704 US 412 Phone: +1 608 504 7776 413 Email: mark@internetpolicyadvisors.com