idnits 2.17.1 draft-farrell-iotsu-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 (May 20, 2016) is 2892 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 403 -- Looks like a reference, but probably isn't: '2' on line 405 -- Looks like a reference, but probably isn't: '3' on line 408 Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Farrell 3 Internet-Draft Trinity College Dublin 4 Intended status: Informational May 20, 2016 5 Expires: November 21, 2016 7 Some Software Update Requirements 8 draft-farrell-iotsu-00 10 Abstract 12 The importance of software update as a mitigation for vulnerabilities 13 discovered after deployment is widely recognised for both desktop and 14 data centre applications and infrastructure. However, in the case of 15 smaller devices, whether running on challenged networks or platforms 16 or not, the situation is much worse, perhaps a decade or more behind 17 that in better developed contexts. This memo proposes requirements 18 for software update in situations where none is currently deployed, 19 argues that that is the right target. In doing this, and perhaps 20 somewhat in contrast to a vendor-driven approach, the interests of 21 the individual device owner are emphasised. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on November 21, 2016. 40 Copyright Notice 42 Copyright (c) 2016 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Arguments for some infrastructure . . . . . . . . . . . . . . 3 59 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 60 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 61 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 7 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 63 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 8.1. Informative References . . . . . . . . . . . . . . . . . 8 66 8.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 69 1. Introduction 71 This is a contribution to the IoTSU workshop. [1] It is not expected 72 to ever become an RFC, but who knows? 74 The context for this memo is software update for devices that today 75 lack a workable software update mechanism. That includes many or 76 perhaps most very small (sometimes so-called "IoT") devices such as 77 sensors and actuators, but also larger devices, such as printers, 78 hubs and switches, WiFi access points and home routers. While there 79 will be some implementation and deployment differences between 80 different classes of device (e.g. very tiny devices might struggle 81 with more onerous cryptography or network connectivity requirements), 82 we believe many similar requirements apply in all these cases so 83 considering common solutions and frameworks should be technically 84 tractable. 86 All code has bugs that will need fixing, and all systems of whatever 87 size will run code that includes bugs. (The author would welcome a 88 better reference than this blog. [2] ) And some bugs will make a 89 system vulnerable to failure. So the base requirement is to be able 90 to update code to fix bugs and make systems less vulnerable. In 91 addition to inadvertent bugs however, there are also bad actors on 92 the Internet, who will search for and exploit vulnerabilities 93 wherever those are found. Devices deployed for any extended duration 94 will inevitably be subject to such attack. 96 It is important to recognise that the searching-for part of that is a 97 solved problem for the public IPv4 Internet [zmap] and is likely to 98 be solved for the public IPv6 Internet. [RFC7707] And even if some 99 devices are not directly accessible from the public Internet, many 100 are, [secconsult] and transitioning "sideways" inside a breached 101 network is a standard mode of operation for attackers and can be 102 automated. 104 One might object that some smaller devices are not really sensitive, 105 e.g. that a bad actor taking over a single thermostat, while 106 possible, could be harmless. Such bad actors may however be 107 attempting to leverage one vulnerabilitiy as a lauch-pad to attack 108 other systems, as was the case with the Heating, Ventillation and Air 109 Conditioning (HVAC) system used to start a major recent breach, 110 [target] or as part of a pervasive monitoring [RFC7258] attack. 112 If we do manage to get a software update mechanism deployed, that 113 system may itself include vulnerabilities. So if, as seems likely, 114 cryptography is used to authenticate updates, then the signing keys 115 used will be a very tempting target to attack. [update-msc] Such 116 attacks are also more likely to succeed if there are very many such 117 signing keys maintained by many vendors, some of whom will not be 118 particularly well qualified to do that particular job. Some other 119 vendors might even try to use a software update mechanism as part of 120 a strategy to lock-in their customers. While no software update 121 mechanism is likely to be able to counter such business choices, from 122 the device owner perspective a vendor acting in that way is yet 123 another bad-actor, and ought be treated as such. Both of these 124 issues point towards considering a set of requirements and solutions 125 where it is possible for some third parties to be involved in 126 software update for many developers of devices. 128 One conclusion to reach here is that all devices are currently 129 vulnerable to attack. If we select a random device, it may be that 130 nobody knows the currently viable attacks that would work today, but 131 we certainly know that some vulnerabilities are known, or will be 132 found, for that device, once effort is expended on finding those. It 133 is therefore, in the author's opinion, irresponsible to deploy 134 devices for extended durations that we know have vulnberabilities, 135 even if those are currently unknown, without some workable form of 136 software update. It follows that all devices require software 137 update. 139 2. Arguments for some infrastructure 141 Earlier, we described the context here as relating to those devices 142 deployed on the Internet for which no working software update 143 mechanism is deployed. That is a little different from the scope of 144 the workshop call for papers, which focused only on the so-called 145 "IoT" space. In this section, we provide arguments for why that 146 broader scope is the better one. 148 So long as there are any widely deployed devices with no software 149 update, those will be exploited. It therefore makes sense to at this 150 stage consider a broader range of devices than only those that are 151 most-constrained. "Solving" the problem for only a specific class of 152 device or network does not solve the problem. 154 The existence of open-source software and hardware, as well as 155 "mixed" products (e.g. closed-hardware running some variety of 156 almost-all GPL'd linux code), together with the number and size of 157 the vendors of such equipment, means that such vendors and specific 158 device deployments will not be of sufficient scale to by themselves 159 support a specific software update infrastructure. Some sharing of 160 infrastructure is therefore required, and that means that it's very 161 unlikely that such infrastructure will be completely specific to one 162 class of device or network. 164 Even where a vendor has found or been informed of a vulnerability, 165 and has developed a patch or update, there are still many issues 166 around the distribution of that. (Here's [3] a timely case in 167 point.) Arguably, announcing but then failing to effectively 168 distribute updates is worse than doing nothing, as patches themselves 169 can be a source for malware developers. There is also a major 170 difficulty with locating patches and with typing of update containers 171 (tarball, zip, OS-specific executable, etc) that needs to be 172 addresses in a more scalable manner over many vendors. 174 Devices in homes that benefit from software update will likely need 175 to connect to some service on the public Internet in order to poll 176 for updates. Let's assume all such traffic is encrypted as is 177 proper, typically via use of TLS with server authentication. We need 178 ways in which we can distinguish that traffic from potentially 179 nefarious spying being done by devices. If many devices poll some 180 pieces of shared infrastructure that only support software update 181 then the probability that we engineer that well, and that workable 182 control features are developed for end-user or home networks 183 increases. 185 Vendors buy and sell one another, and cease to exist and products are 186 end-of-life'd. Open-source projects can wither away over time. All 187 of those mean that we need some form of infrastructure that will 188 still be present despite such changes. 190 Device owners cannot be expected to know much or anything about 191 software update, so any measures of quality or attempts to detect 192 misbehaviours will require some form of observatory or audit. That 193 means that we need there to be an auditable number of sources for 194 distributing software updates. Wth O(10^3) or fewer sources, that 195 seems quite doable. With O(10^6) sources, that would appear to be 196 significantly harder. 198 3. Requirements 200 In this section we posit some requirements for software update. We 201 do not intend this to be an exhaustive list, but rather to be a list 202 that captures key requirements for systems that do not currently have 203 a working software-update mechanism. 205 We also make no claim that this is an authoritative list, rather this 206 is a list to try start a discussion with those who implement and 207 deploy devices and the software update infrastructure those will 208 need. 210 In the author's opinion, the actual deployment of some software 211 update scheme is far more important than meeting any specific subset 212 of these requirements - once we can update a system then we can fix 213 anything, given enough time and interest. (That seems to indicate 214 there will be value in trying to construct a minimal list of 215 requirements.) 217 Requirements posited below are numbered for ease of reference. 219 R1 All devices that have software or firmware that can be updated 220 should be able to use a software update infrastructure developed 221 to meet these requirements, regardless of whether that device is 222 open- or closed-source, is made by a for-profit vendor or a 223 community or academic projecct. 225 R2 One device can require software update from multiple sources, 226 e.g., there can be different chips on a single board from 227 different vendors. Or a larger device might have a "native" 228 operating system inside which various containers are used to run 229 applications, possibly with entirely different operating systems. 231 R3 Those update systems might need to co-operate, e.g. so that 232 only one object needs to be downloaded to update multiple 233 subsystems within the device. 235 R4 That co-operation might simply involve some kind of 236 packaging of different otherwise indpendent sofware 237 update objects so that co-ordination is mostly around 238 transport and some form of meta-packaging. 240 R5 Co-operation might require that one system under the 241 device owner's control act as a local server for software 242 update. In the case of a device with a "native" and 243 several "guest" OSes, one of these might be seen by the 244 others as the source of software updates. 246 R6 In other cases, the device can take part in multiple 247 independent software update schemes, with no co-ordination 248 being needed. 250 R7 Data origin authentication is required, and overwhelmingly likely 251 to be provided via a digital signature mechanism. 253 R8 There may be some systems where signature verification does 254 not happen on the device to be updated but instead on some 255 other upstream device - this can be because of algorithm 256 implementation issues, or due to issues with Public Key 257 Infrastructure (PKI) if say signature verification requires 258 certificate status checking, which requires support for HTTP, 259 which can again be too onerous for some systems. 261 R9 More than one PKI may need to be supported in updating even 262 one device. There are widely deployed systems based on an 263 X.509 PKI, others based on OpenPGP and perhaps others based 264 on home-grown concepts similar to a PKI. [update-msc] 266 R10 It is very likely that multiple signers may need to be part 267 of a solution, e.g. authenticating the orgin of the software 268 separately from the download repository or perhaps separately 269 authenticating the origin of a collection of updates from 270 that for each member of a collection. 272 R11 It needs to be possible for sources of software to change, under 273 the control of the device owner. The relevant software sources 274 may or may not be co-operating with such changes. 276 R12 In the case of end-of-life devices, if there is a (typically 277 open-source) community who could manage future updates then 278 it is important to enable this without the device owner 279 having to hack into ("root") their own device. (That last 280 should be considered an anti-pattern in this context.) 282 R13 There may be devices where a choice of software sources 283 exist. While there may be challenges in how to offer a user 284 interface to allow the device owner such a choice, it must be 285 possible to offer such choices where they exist. 287 R14 Devices will need to poll for software update. It seems unlikely 288 that most devices can act as a server listening for incoming 289 connections from software sources. That means that devices will 290 need to establish a way to connect to a software source, or some 291 entity who can distribute updates. 293 R15 When the device is in the home, or carried on a person, then 294 there are significant privacy issues that arise. While in 295 those cases, encrypting the interactions may be required, it 296 may also be required that it is clear to the person (or their 297 home network) that all that is happening is software update. 298 To give a concrete example, the author would be happy if a 299 television called home to check for a software update, but 300 very unhappy if the same device called home to tell someone 301 what channel changes are occurring. 303 4. Security Considerations 305 While software update does mitigate vulnerabilities, it also creates 306 new vulnerabilities. First, software signing private kes are a 307 hugely attractive target, and have subject to real attacks in the 308 past. [flame] 310 The software updates that are distributed are also usable to re- 311 create the vulnerabilities that are being fixed, so that unpatched 312 systems are put at further risk once the patch details reach a bad 313 actor, which is impossible to prevent. Automation of attack- 314 generation code is also possible, [auto] though still difficult. 315 That could allow bad actors to exploit the time window during which 316 updates propogate to the deployed base. There are therefore good 317 reasons to try to minimise this duration. 319 Patches can also include new vulnerabilities. While this is true, 320 that is out of scope for this document which considers the software 321 update mechanisms and not the quality of the software being updated. 323 5. Privacy Considerations 325 If the software update mechanism exposes any correlatable identifier 326 then it becomes a useful way to track people who carry devices that 327 poll for updates. 329 Devices within homes or vehicles or other sensitive locations can 330 also expose privacy sensitive information via the software update 331 mechanism. For example, if the device polls the update server on 332 power-on, and if power-on is associated with some event such as a 333 homeowner arriving home, then the existence of the packets 334 (regardless of encryption) leaks some possibly privacy sensitive 335 information. 337 We will likely want to use a confidentiality service in order to not 338 expose identifiers to network attackers. That creates the potential 339 for the device to use the software update channel (or any other 340 indistinguishable channel) as a covert channel. Devices have been 341 known to exfiltrate privacy sensitive data for the benefit of the 342 device maker [refs] so if we can provide some way to increase 343 confidence that only software update is happening, then that can be 344 beneficial for all concereed (except bad actors). It may help if 345 many devices poll some well-known services/hosts on the Internet and 346 do not call-home to the device maker's network. 348 6. IANA Considerations 350 This document makes no requests for IANA action. This section would 351 be removed except it won't be as we're not aiming for publication as 352 an RFC. 354 7. Acknowledgements 356 TBD - your name here for comments or beer! But that assume there'll 357 be another revision of this which may not happen. 359 8. References 361 8.1. Informative References 363 [auto] Brumley, D., Poosankam, P., Song, D., and J. Zheng, 364 "Automatic patch-based exploit generation is possible: 365 techniques and implications", 2008, 366 . 369 [flame] Sotirov, A., "Analyzing the md5 collision in flame", 2012, 370 . 373 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 374 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 375 2014, . 377 [RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 378 Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016, 379 . 381 [secconsult] 382 Viehbock, S., "House of Keys: Industry-Wide HTTPS 383 Certificate and SSH Key Reuse Endangers Millions of 384 Devices Worldwide.", 2015, . 388 [target] Weiss, N. and R. Miller, "The target and other financial 389 data breaches: frequently asked questions", 2015. 391 [update-msc] 392 Ruissen, P. and R. Vloothuis, "Insecurities within 393 automatic update systems v1. 16", 2007, 394 . 397 [zmap] Durumeric, Z., Wustrow, E., and J. Halderman, "Zmap: fast 398 internet-wide scanning and its security applications.", 399 2013. 401 8.2. URIs 403 [1] https://down.dsg.cs.tcd.ie/iotsu/ 405 [2] https://amartester.blogspot.ie/2007/04/bugs-per-lines-of- 406 code.html 408 [3] http://arstechnica.com/security/2016/05/foul-mouthed-worm-takes- 409 control-of-wireless-isps-around-the-globe/ 411 Author's Address 413 Stephen Farrell 414 Trinity College Dublin 415 Dublin 2 416 Ireland 418 Phone: +353-1-896-2354 419 Email: stephen.farrell@cs.tcd.ie