idnits 2.17.1 draft-farrell-iotsi-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 (February 19, 2016) is 2990 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 301 -- Looks like a reference, but probably isn't: '2' on line 303 -- Looks like a reference, but probably isn't: '3' on line 306 -- Looks like a reference, but probably isn't: '4' on line 308 -- Looks like a reference, but probably isn't: '5' on line 311 -- Looks like a reference, but probably isn't: '6' on line 313 -- Looks like a reference, but probably isn't: '7' on line 315 -- Looks like a reference, but probably isn't: '8' on line 317 == Outdated reference: A later version (-08) exists of draft-hardie-privsec-metadata-insertion-00 == Outdated reference: A later version (-08) exists of draft-ietf-dhc-anonymity-profile-07 == Outdated reference: A later version (-06) exists of draft-jennings-core-senml-04 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 9 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 A. Cooper 5 Expires: August 22, 2016 Cisco 6 February 19, 2016 8 It's Often True: Security's Ignored (IOTSI) - and Privacy too. 9 draft-farrell-iotsi-00 11 Abstract 13 Designers of information models for challenged devices connected to 14 the Internet, and most especially for devices that will be carried by 15 people or that will be operating in people's homes, need to not 16 forget that people own the devices and the data, and expect those to 17 work for them, not against them. This draft discusses some security 18 and privacy issues that may be relevant for the IAB's IOTSI workshop 19 on information models for such devices and related services. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on August 22, 2016. 38 Copyright Notice 40 Copyright (c) 2016 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Ownership and Privacy . . . . . . . . . . . . . . . . . . 3 57 1.2. Life Cycle . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.3. Imperfection . . . . . . . . . . . . . . . . . . . . . . 5 59 2. Commercial Considerations . . . . . . . . . . . . . . . . . . 5 60 3. Security Considerations . . . . . . . . . . . . . . . . . . . 6 61 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 63 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 64 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 7.1. Informative References . . . . . . . . . . . . . . . . . 6 66 7.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 69 1. Introduction 71 This is a contribution to the IAB IOTSI workshop. [1] It is not 72 expected to ever become an RFC. 74 The IETF has recognised the need for strong security mechanisms 75 [RFC3365] to be defined for all IETF protocols. The IETF has further 76 recognised the potential for pervasive monitoring and that work to 77 counter that is needed [RFC7258] and the IAB has produced guidelines 78 for handling privacy in Internet protocols. [RFC6973]. This draft 79 aims to identify some issues with the above that may arise with 80 respect to the information models that are the topic of the IOTSI 81 workshop, but that might othewise get forgotten. Let's start from 82 just a few high-level principles that ought inform designs: 84 1. Don't forget that the user owns the device and, arguably, the 85 data produced related to that device. 87 2. Don't forget that the device needs to be updated and that the 88 vendor will end-of-life the device, but the above still needs to 89 be remembered. 91 3. Don't forget that while we can secure information elements in 92 transit and in storage, that will always be imperfect and 93 information will leak out. 95 It is worth noting that the IOTSI call for submissions itself did 96 ignore all of these issues. 98 For each of the above, we'll list a few issues, with some references 99 that may help in further discussion. A full analysis of how each of 100 these ought be reflected in requirements, in specifications of 101 information models and subsequently in data models and protocols is 102 not a goal here, nor is completeness, the goal for now is simply to 103 try ensure that these issues are considered in the IOTSI workshop. 105 1.1. Ownership and Privacy 107 1. Regardless of the current legal situation in any particular 108 jurisdiction, it is inevitable that somewhere, sometime, the user 109 will be considered the legal owner of the data emitted by devices 110 relevant to this discussion, sometimes in inventive or disruptive 111 ways. [2] Information models need to not assume that all 112 information elements are "fair game" for all uses by service 113 providers, e.g. no matter how problematic it may be for service 114 providers, explicitly informed consent may be needed to include 115 some data in aggregates. And that might impose a need for what 116 could end up being overly-complex permissions handling for pretty 117 much any element in information models. Managing that without 118 being overwhelmed by complex models may be hard. 120 2. Don't depend on opaque end-user or legal agreements - users do 121 not, and you are likely to generate terrible publicity if your 122 device or service gets popular. [3] Information models that avoid 123 this error are likely to involve additional entities, such as 124 local controllers that might allow an end-user some control over 125 what their devices are doing. 127 3. Don't include long-term stable unique identifiers anywhere, and 128 do seriously attempt to avoid all such. You will never know how 129 your information model will be reused or abused. 130 [ishtiaq2010security] While this may seem obvious, it will get 131 forgotten even by people who generally are attempting to be 132 privacy-friendly. In particular using MAC addresses 133 ([I-D.jennings-core-senml] Section 6.1.2) in this way is actively 134 harmful to privacy and in the case of the DHCP protocol, fixing 135 that years later requires a significant specification 136 [I-D.ietf-dhc-anonymity-profile] and implementation effort, and 137 it remains to be seen if such work will get widely deployed or 138 not. It is far better to be highly conservative in the initial 139 stages of work, (where IOTSI is) so that such remedial efforts 140 are not required later. 142 4. In some circumstances designing systems involving constrained 143 devices involves trade-offs between efficient use of resources 144 and privacy. For example, leveraging hardware identifiers at the 145 application layer may allow for compression or help conserve 146 bandwidth usage, but may also create additional avenues for 147 attack as compared to using compartmentalized application-layer 148 identifiers. At the point of specifying information models, 149 decisions about how individual systems will navigate these trade- 150 offs should not be taken for granted. Rather, information models 151 should be specified to support privacy-enhancing decisions at the 152 system level, with optional support for less-privacy-enhancing 153 decisions in situations where deployment constraints are expected 154 to warrant such support. 156 5. Traffic patterns or content, even if "anonymised" can be 157 identifying in unexpected ways, either intrinsically [4] or via 158 correlation. [5] Even the existence/non-existence and timing of 159 application or inftastructure (e.g. DNS, DHCP) traffic can 160 reveal presence or more. Naive information models that don't 161 consider these issues are more likely to result in vulnerable 162 systems. 164 6. Distinctions between "data" and "meta-data" may not be 165 significant when considering privacy and security - an 166 information or data model or protocol that assumes that e.g. only 167 "data" needs confidentiality is likely broken, as meta-data and 168 traffic patterns may fully breach privacy. There is also a 169 tendency to re-inject data that is carried in ciphertext form 170 into wrappers or headers that are considered meta-data and 171 carried in clear or exposed at too many middleboxes. That anti- 172 pattern is one to be strongly discouraged. 173 [I-D.hardie-privsec-metadata-insertion] 175 1.2. Life Cycle 177 1. All devices of any kind will include vulnerabilities. If device 178 software/firmware is not updated, those will eventually be 179 exploited somewhere, sometime. Crawling the network to find 180 those vulnerble devices is a solved problem. [6] 182 2. The end-user will want the device to continue working and 183 continue getting updated even after all vendors and service 184 providers initially involved have end-of-life'd everything 185 involved. In principle, everything (DNS names, services, roots 186 of trust for software update) needs to be something that can be 187 updated even then. End-of-life is clearly a more complex issue 188 than is typically considered (as shown by the list at [7] which 189 was just a first hit for a search). 191 1.3. Imperfection 193 1. We do have ways to protect data in transit and in storage, but we 194 cannot depend on those protecting any information element all of 195 the time. Even with best practices, eventually, some fields from 196 some protocols will leak. All layers need to do as much as 197 possible to provide security and avoid privacy leaks. [8] 199 2. Even where (structured) data is encrypted, there may still be 200 ways to analyse the traffic to expose the information content. 201 [RFC6562] for example shows that variable bit rate audio with 202 secure RTP can expose audio. And encoded audio is often much 203 more complex than the information considered here. 205 2. Commercial Considerations 207 At present, many devices and services are sold and operate in ways 208 that do not take account of the considerations listed here. That is 209 often done for pragmatic and/or commercial reasons, due to the 210 inability to reliably contact devices from the parts of the Internet 211 about which we care, or sometimes in an effort by a vendor or 212 service-provider to achieve "lock-in" so that a user has a hard time 213 mixing and matching the devices and services that the user prefers. 214 And sometimes, users won't have sufficient technical ability to make 215 a device and/or service work for them, even if the vendor or service- 216 provider does expose interfaces allowing for security and privacy 217 friendly deployment. 219 In this document, the term "service provider" is used consistent with 220 the above, to mean some application service that is not under the 221 control of the device owner or end-user, but rather is controlled by 222 someone else, likely the device vendor or a partner of theirs. 224 While such cases are a reality and the norm today, and while it is 225 often unclear how to move from there towards a situation where 226 devices and services promote interoperability, the basic information 227 models developed for these devices and services should not preclude a 228 future in which a user can exert independent control over these 229 deployments. 231 It seems likely from the above that information models will need to 232 include some conception of the device owner as a first-class, but 233 hopefully pseudononymous, entity and not be solely limited to 234 consideration of characteristics of devices and services. 236 3. Security Considerations 238 Yes, there are. Are you shocked? 240 4. Privacy Considerations 242 Yes, there are. Aren't you shocked yet? :-) 244 5. IANA Considerations 246 This document makes no requests for IANA action. This section would 247 be removed except it won't be as we're not aiming for publication as 248 an RFC. 250 6. Acknowledgements 252 TBD - your name here for comments or beer! 254 7. References 256 7.1. Informative References 258 [I-D.hardie-privsec-metadata-insertion] 259 Hardie, T., "Design considerations for Metadata 260 Insertion", draft-hardie-privsec-metadata-insertion-00 261 (work in progress), October 2015. 263 [I-D.ietf-dhc-anonymity-profile] 264 Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity 265 profile for DHCP clients", draft-ietf-dhc-anonymity- 266 profile-07 (work in progress), February 2016. 268 [I-D.jennings-core-senml] 269 Jennings, C., Shelby, Z., Arkko, J., and A. Keranen, 270 "Media Types for Sensor Markup Language (SENML)", draft- 271 jennings-core-senml-04 (work in progress), January 2016. 273 [RFC3365] Schiller, J., "Strong Security Requirements for Internet 274 Engineering Task Force Standard Protocols", BCP 61, RFC 275 3365, DOI 10.17487/RFC3365, August 2002, 276 . 278 [RFC6562] Perkins, C. and JM. Valin, "Guidelines for the Use of 279 Variable Bit Rate Audio with Secure RTP", RFC 6562, DOI 280 10.17487/RFC6562, March 2012, 281 . 283 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 284 Morris, J., Hansen, M., and R. Smith, "Privacy 285 Considerations for Internet Protocols", RFC 6973, DOI 286 10.17487/RFC6973, July 2013, 287 . 289 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 290 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 291 2014, . 293 [ishtiaq2010security] 294 Ishtiaq Roufa, R., Mustafaa, H., Travis Taylora, S., Xua, 295 W., Gruteserb, M., Trappeb, W., and I. Seskarb, "Security 296 and privacy vulnerabilities of in-car wireless networks: a 297 tire pressure monitoring system case study", 2010. 299 7.2. URIs 301 [1] https://www.iab.org/activities/workshops/iotsi/ 303 [2] https://www.economist.com/blogs/schumpeter/2014/06/who-owns-your- 304 personal-data 306 [3] http://techcrunch.com/2015/02/08/telescreen/ 308 [4] http://www.economist.com/blogs/schumpeter/2014/06/who-owns-your- 309 personal-data 311 [5] https://en.wikipedia.org/wiki/Netflix_prize#Privacy_concerns 313 [6] https://www.shodan.io/ 315 [7] https://www1.good.com/support/end-of-life-notices.html 317 [8] https://en.wikipedia.org/wiki/AOL_search_data_leak 319 Authors' Addresses 321 Stephen Farrell 322 Trinity College Dublin 323 Dublin 2 324 Ireland 326 Phone: +353-1-896-2354 327 Email: stephen.farrell@cs.tcd.ie 328 Alissa Cooper 329 Cisco 330 707 Tasman Drive 331 Milpitas, CA 95035 332 USA 334 Email: alcoop@cisco.com