idnits 2.17.1 draft-mcfadden-smart-threat-changes-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 9, 2020) is 1508 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? 'RFC3552' on line 81 looks like a reference -- Missing reference section? 'IANA-WKP' on line 158 looks like a reference -- Missing reference section? 'RFC854' on line 162 looks like a reference -- Missing reference section? '2' on line 172 looks like a reference -- Missing reference section? 'Arkko' on line 267 looks like a reference -- Missing reference section? 'RFC6454' on line 276 looks like a reference Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). 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 March 9, 2020 4 Expires: September 9, 2020 6 BCP72 - A Problem Statement 7 draft-mcfadden-smart-threat-changes-00.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 months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 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 September 9, 2020. 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 respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 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 really changed? Or, is the model described in 54 RFC3552 still largely accurate? This draft attempts to describe an 55 non-exhaustive list of changes in the current threat environment. It 56 suggests that there are both qualitative and quantitative differences 57 from the environment described in RFC3552 and is intended as input to 58 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...................................................6 71 5. Problem Statement..............................................7 72 6. Security Considerations........................................8 73 7. IANA Considerations............................................8 74 8. References.....................................................8 75 8.1. Normative References......................................8 76 8.2. Informative References....................................8 77 9. Acknowledgments................................................8 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 might 97 then be used as input into the IAB's model-t process for documenting 98 why an update to BCP72 might be needed. 100 Reconsideration of the guidelines for writing Security Considerations 101 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 into 107 two groups: passive attacks where an attacker has only limited, or 108 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 model 112 in this way also allows for the model to incorporate attacks that 113 come from resources not at endpoints. In fact, an entire subsection 114 of the BCP discusses on-path versus off-path attacks. 116 2.1. BCP72 Passive Attacks 118 BCP72 details describes passive attacks as those in which an attacker 119 "reads off the network but does not write them." It then gives some 120 specific examples including password sniffing, attacks on routing 121 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 passive 125 attack considered is one in which an attacker uses read-only access 126 to packets to extract otherwise private information. BCP72 discusses 127 the problems encountered when packets are transported without some 128 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 read off the 132 network. The attacker then mounts a cryptographic attack on those 133 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 an an active attack." In this case, the BCP discusses 140 spoofing packets 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 {1} show orders of magnitude 153 increases in the size of attacks. Recent studies show that the vast 154 majority of attacks come from attackers using automated, distributed 155 tools. This makes a threat model that is built around the notion of 156 a single attacker inapplicable in the current Internet. 158 Studies also show that certain well-known ports [IANA-WKP] are the 159 primary targets for this large jump in automated attacks. Ports 445, 160 22, 23, and 1433 make up 99% of the targets. 162 The growth in the attacks on Telnet [RFC854] is a reflection of 163 another development in the public Internet: the growth in numbers of 164 constrained devices. Endpoints that are not capable of supporting 165 endpoint protection software, effective encryption, or proper 166 authentication have proliferated on the public Internet. That many 167 of these devices do not have facilities for either self-protection or 168 protecting against becoming a threat on their own has been documented 169 in an IAB Workshop {IAB-IOT]. 171 Since 2003, there have been a variety of studies examining the growth 172 in the number of devices connected to the Internet[2]. At the time 173 of writing, one estimate is that the difference between the number of 174 devices connected in 2003 and 2020 is in the region of 22 billion. 175 The sheer quantity of devices means that the Internet's attack 176 surface is significantly expanded. Quantitative surveys also 177 indicate that the greatest growth is in so-called enterprise IoT and 178 household automation. The security properties of these endpoints are 179 potentially different from hosts that made up the majority of the 180 Internet in 2003. 182 Another important quantitative change to the structure of the 183 Internet is the consolidation of its infrastructure. While BCP72 is 184 certainly correct in its focus on the technologies and protocols that 185 can be exploited by attackers, it is hard to ignore the fact that the 186 threat landscape has been affected by the emergence of consolidation. 187 One example of this would be commercial or governmental surveillance 188 capabilities. In an environment where there are a small number of 189 very large entities that control the fabric of connectivity and 190 content, the threat landscape is affected by the fact that it may be 191 easier to exert control and implement attacks on a small number of 192 organizations. 194 3.2. Qualitative Changes 196 The Internet in 2003 had a relatively small number of types of host. 197 The client/server model of computing remained important at that time 198 and endpoints were relatively homogeneous. 200 The diversity of deployment is an important part of the contemporary 201 Internet landscape. Not only is there a measurable and huge increase 202 in the number of endpoints (greatly increasing the attack surface), 203 but there is rich diversity in the capacity, connectivity, purpose of 204 those endpoints. As a result, while the number of protocols may have 205 not increased exponentially, the kinds of devices that can be sources 206 or targets of exploits has increased significantly. 208 The threat landscape is also affected by the balance between 209 convenience versus protection from threats. Today's landscape is 210 affected by the conflict between protection from attackers and 211 threats, and convenience. Applications and services fight for market 212 and mind share by being the easiest to adopt, install and use. Many 213 users treat security and protection in the same way that they treat 214 personal health - they ignore it until there is a serious problem and 215 then expect the problem to be mitigated quickly. 217 The class of attackers has changed as well. In 2003, advanced 218 persistent attacks hadn't yet been given that name and the estimated 219 monetary loss to attackers was estimated to the less than $1 billion 220 ISD. The emergence of scripted and other automated tools has changed 221 the landscape dramatically. In 2019, one estimate of losses due to 222 network based attacks was in excess of $315 billion. This is the 223 direct result of the speed, financing and flexibility of those doing 224 the attacking. 226 It is true that, since BCP 72 was published there have been 227 significant improvements to communications security. This includes 228 securing the transport layer through protocols such as TLS 1.3, 229 HTTP/2 and secure SMTP. However, secure transport does not prevent 230 rogue applications from executing attacks even when secure transport 231 is in place. Another example of this happens when VPNs themselves 232 examine or exploit traffic rather than do what they are advertised to 233 do. 235 3.3. Data at Rest 237 The Internet Threat model in BCP72 primarily speaks to data being 238 transmitted, transited or received over the network. More recent 239 approaches to providing services over the Internet involve 240 intermediate nodes that may redirect, manipulate or store traffic. 241 While technologies such as exchange points may be seen to simply part 242 of the fabric between senders and receivers, the insertion of content 243 networks, caches and traffic analyzers has become ubiquitous. 245 These middle boxes play an important role in content provision, 246 analysis and security in today's Internet. They were in limited use 247 when BCP72 was published. The importance of these middleboxes is such 248 that, when protocols are developed that effectively route around 249 them, operators and content providers sometimes object. 251 Any contemporary Internet threat model must go beyond the threats to 252 traffic as it moves from Alice to Bob. Beyond intermediaries, the 253 more personal digital devices there are, the more difficult it is to 254 control and protect them. The threat model should also include 255 attacks that take place when the data is at rest or being manipulated 256 for operational reasons. 258 4. Observations 260 If the IAB's Model T program finds that there have been both 261 quantitative and qualitative changes to the Internet threat model, 262 then perhaps it would be time to consider revising BCP72 to reflect 263 those changes. In this case the IAB should provide some initial 264 assistance to the IETF on how to proceed with the revision. Others 265 have argued that the end-to-end architecture model of the Internet 266 cannot be understood by just considering all of the protocol layers 267 up to the application layer.[Arkko] 269 In addition, BCP72's concentration on the communication channel fails 270 to account for two of the central developments of the Internet in the 271 last ten years: the rise of the application as the endpoint and the 272 diversity of endpoints that are publicly connect. 274 It might also be observed that there have already been limited 275 attempts to reconsider BCP72's threat model. As an example, the 276 Same-Origin Policy detailed in [RFC6454] shows how an application- 277 layer protocol can protect itself against certain kinds of attacks 278 based on the concept of origin (the determination and use of an 279 origin URI). 281 Finally, protection from phishing attacks in the presence of certain 282 implementations of IDNA means that applications are implementing 283 protections against certain types of attacks. This is another 284 example of how the application layer imposes controls on an otherwise 285 secure communication channel. 287 These are intended as only examples of how the landscape has changed. 288 It seems clear that many more changes exist and need to be researched 289 and documented. 291 5. Problem Statement 293 BCP72 is an accurate reflection of the security threat landscape at 294 the time which it was written. While the work of the IAB program on 295 the Internet threat model is essential, a revision to RFC3552 is in 296 the remit of the IETF. 298 BCP72 represents a too narrow view of the Internet's threat 299 landscape. An update is needed to: 301 . Reflect the diversity of endpoint deployment on the Internet; 303 . Document the impact of application-based security on the more 304 narrow communication channel model (possibly: consideration of 305 data in use in addition to data in motion); 307 . Account for data at rest as part of the model as well as data 308 in motion; 310 . Reflecting on the how the growth of the number of devices 311 connected affects the attack surface for the Internet at large; 313 . Research by the IAB and others on how a new, contemporary 314 threat model might be described and communicated to protocol 315 designers and others; and, 317 . Make constructive suggestions for an approach (or, methodology) 318 for the IETF to revise BCP72. 320 6. Security Considerations 322 This document is entirely about security on the Internet and is 323 intended as input into the IAB's Model T work. 325 7. IANA Considerations 327 The memo has no actions for IANA 329 8. References 331 8.1. Normative References 333 8.2. Informative References 335 Informational references are to be added to a later version of this 336 draft. 338 9. Acknowledgments 340 This document was prepared using 2-Word-v2.0.template.dot. 342 Authors' Addresses 344 Mark McFadden 345 Internet policy advisors llc 346 513 Elmside Blvd 347 Madison WI 53704 US 349 Phone: +1 608 504 7776 350 Email: mark@internetpolicyadvisors.com