idnits 2.17.1 draft-tenoever-hrpc-anonymity-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC6973], [Pew], [RFC3552]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 12, 2017) is 2358 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 392 -- Obsolete informational reference (is this intentional?): RFC 7626 (Obsoleted by RFC 9076) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Human Rights Protocol Considerations Research Group S. Bortzmeyer 3 Internet-Draft AFNIC 4 Intended status: Informational N. ten Oever 5 Expires: May 16, 2018 ARTICLE 19 6 November 12, 2017 8 Anonymity, Human Rights and Internet Protocols 9 draft-tenoever-hrpc-anonymity-01 11 Abstract 13 Anonymity is less discussed in the IETF than for instance security 14 [RFC3552] or privacy [RFC6973]. This can be attributed to the fact 15 anonymity is a hard technical problem or that anonymizing user data 16 is not of specific market interest. It remains a fact that 'most 17 internet users would like to be anonymous online at least 18 occasionally' [Pew]. 20 This document aims to break down the different meanings and 21 implications of anonymity on a mediated computer network. 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 May 16, 2018. 40 Copyright Notice 42 Copyright (c) 2017 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. Vocabulary Used . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Should protocols promote anonymity? . . . . . . . . . . . . . 4 60 4. Example of use cases . . . . . . . . . . . . . . . . . . . . 5 61 4.1. Simultaneous use . . . . . . . . . . . . . . . . . . . . 5 62 4.2. Successive use . . . . . . . . . . . . . . . . . . . . . 5 63 5. Practical advices . . . . . . . . . . . . . . . . . . . . . . 5 64 5.1. Protocol developers . . . . . . . . . . . . . . . . . . . 5 65 5.2. Protocol implementors . . . . . . . . . . . . . . . . . . 6 66 6. Open Questions . . . . . . . . . . . . . . . . . . . . . . . 6 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 69 9. Research Group Information . . . . . . . . . . . . . . . . . 7 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 10.1. Informative References . . . . . . . . . . . . . . . . . 7 72 10.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 75 1. Introduction 77 There seems to be a clear need for anonymity online in an environment 78 where harassment on the Internet is on the increase [Pew2] and the UN 79 Special Rapporteur for Freedom of Expression calls anonymity 80 'necessary for the exercise of the right to freedom of opinion and 81 expression in the digital age' [UNHRC2015]. 83 Nonetheless anonymity is not getting much discussion at the IETF, 84 providing anonymity does not seem a (semi-)objective for many 85 protocols, even though several documents contribute to improving 86 anonymity such as [RFC7258], [RFC7626], [RFC7858]. 88 There are initiatives on the Internet to improve end users anonymity, 89 most notably [torproject], but these initiatives rely on adding 90 encryption in the application layer. 92 This document aims to break down the different meanings and 93 implications of anonymity on a mediated computer network and to see 94 whether (some parts of) anonymity should be taken into consideration 95 in protocol development. 97 2. Vocabulary Used 99 Concepts in this draft currently strongly hinges on [AnonTerm] 101 Anonymity A state of an individual in which an observer or attacker 102 cannot identify the individual within a set of other individuals 103 (the anonymity set). [RFC6973] 105 Linkability Linkability of two or more items of interest (IOIs - 106 Items Of Interest, e.g., subjects, messages, actions, ...) from an 107 attacker's perspective means that within the system (comprising 108 these and possibly other items), the attacker can sufficiently 109 distinguish whether these IOIs are related or not. [AnonTerm] 111 Pseudonymity Derived from pseudonym, a persistent identity which is 112 not the same as the entity's given (or official) name. For most 113 (TODO all?) IETF protocols, pseudonimity is a given: protocols 114 don't care whether the identity is an official one or not. But it 115 should be noted that, if the user cannot create new pseudonyms 116 easily, pseudonyms suffer from linkability. Unlikability depends 117 on this ability to create new pseudonyms. TODO: or decide that 118 pseudonyms _require_ this ability to be created at will? 120 Unlinkability Unlinkability of two or more items of interest (IOIs, 121 e.g., subjects, messages, actions, ...) from an attacker's 122 perspective means that within the system (comprising these and 123 possibly other items), the attacker cannot sufficiently 124 distinguish whether these IOIs are related or not. [AnonTerm] 126 Undetectability The impossibility of being noticed or discovered 128 Undetectability of an item of interest (IOI) from an attacker's 129 perspective means that the attacker cannot sufficiently 130 distinguish whether it exists or not [AnonTerm] 132 Unobservability 134 Unobservability of an item of interest (IOI) means: 135 undetectability of the IOI against all subjects uninvolved in it 136 and 138 anonymity of the subject(s) involved in the IOI even against the 139 other subject(s) involved in that IOI. [AnonTerm] 141 It should be noted that the word "anonymity" is both very loaded 142 politically (witness all the headlines about the "darknet") and 143 poorly understood. Most texts talking about anonymity actually refer 144 to pseudonymity (for instance, when people say that "Bitcoin is 145 anonymous"). This confusion is even in the example given in 146 [RFC4949] definition of anonymity. 148 Anonymity is strongly linked to unlinkability: if your actions are 149 linkable, it suffices that one of them is tied to your identity, and 150 anonymity is over. 152 It should be noted that anonymity is not binary: there have been 153 these recent years a lot of progress of desanonymisation techniques. 154 Data is never fully "anonymous", it is only more or less anonymous. 155 [RFC6235] [MITdeano] [Utexas] [Article29] 157 3. Should protocols promote anonymity? 159 The amount of data that is generated by and about individuals is 160 growing exponentially. This can be attributed to the fact that an 161 ever increasing number of actions is digitally mediated, and the 162 increase of connected sensors in the every day environment. Even 163 though these two causes do not fully fall within the scope of the 164 IETF, there is a significant part of these two examples that do. 166 With the increase of data there is also an increasing ability for 167 third parties to analyze human behaviour. It should be noted that 168 any data that could identify an individual is personally identifiable 169 information (PII). This means that information which can be used to 170 distinguish an indivual from other individuals can be considered as 171 personally identiable information. The access and control of 172 personally identifiable information by a third party is a (potential) 173 liability for both the third party and the individual. This 174 liability could for example translate into a physical risk for the 175 individual or into a legal risk for the third party under information 176 security and privacy laws. 178 Some network operators argue that without the opportunity to 179 persistently identify individual users it becomes harder to thwart 180 attacks and troubleshoot network issues. Whereas identification 181 might be helpful to address issues in some cases, it poses an 182 inherent threat to the anonymity of users. Not protecting the 183 anonymity of users leads to a deterioration of the right to privacy, 184 and the right to freedom of opinion and expression. There can be 185 limitations the right to privacy and freedom of expression, but these 186 should always be provided by law and necessary and proportionate to 187 achieve one of a handful of legitimate objectives. 189 Anonymity will always be a balancing act between user protection 190 (which requires a high level of anonymity) and other requirments for 191 operations and research, such as routing information. Anonymity is 192 by no means achieved by default in an online environment, nor has it 193 been a strong consideration in protocol development in the 194 development of the Internet. Increasing anonymity in the digital 195 environment is not an easy task, exactly because the ubiquity of data 196 that is generated and stored. But exactly the fact that we generate 197 so much data urges us to address this issue. 199 4. Example of use cases 201 4.1. Simultaneous use 203 One user may use concurrently several identities, mixing them in 204 operations, while wanting to keep them distinct. The protocol and 205 its implementations should not preclude this use. 207 4.2. Successive use 209 One user may switch from one identity to another. In that case, it 210 must be doable without a "bleedover" from the old identity to the new 211 one. 213 5. Practical advices 215 5.1. Protocol developers 217 First, the protocol should avoid to have mandatory persistent 218 identifiers. 220 Even without persistent identifiers, anonymity could be broken by 221 examining the patterns of access. If an user visits each morning the 222 three same Web sites, always in the same order, it will be easy to 223 identify them even without persistent identifier. Protocol designers 224 should therefore ask themselves if patterns are easily visible, or 225 obfuscated in some way. 227 If the protocol collects data and distributes it (see [RFC6235]), 228 "anonymizing" the data is often suggested but it is notoriously hard. 229 Do not think that just dropping the last byte of an IP address 230 "anonymizes" data. 232 Pay attention to the fact that Internet actors do not all see the 233 same thing. Consider the anonymity of the user with respect to: 235 - local network operator 237 - other networks you connect to 239 - your communications peer on the other end of the pipe 240 - intermediaries ([RFC6973]) 242 - enablers ([RFC6973]) 244 - someone who is in several roles, for instance a big state 245 surveillance agency 247 5.2. Protocol implementors 249 Avoid adding options or configurations that create or might lead to 250 patterns or regularities that are not explicitely required by the 251 protocol. 253 An example is DHCP where sending a persistent identifier as the 254 client name was not mandatory but, in practice, done by many 255 implementations, before [RFC7844]. 257 If an implementation allows for identity management, there should be 258 a clear barrier between the identities to ensure that they cannot 259 (easily) be associated with each other. 261 If there are anonymization option for the protocol, these should be 262 enabled by default. 264 6. Open Questions 266 While analyzing protocols for their impact on users anonymity, would 267 it make sense to ask the following questions: 269 1. How does the protocol impact pseudonymity? If the protocol 270 limits the creation of new pseudonyms, it can limit their 271 usefulness to "hide" an user's identity. For instance, IP 272 addresses are pseudonyms but, since they are not under end 273 users's control, they have strong linkability. That's why they 274 are rightly regarded as personal identifiers [EUcourt]. On the 275 other hand, Bitcoin addresses are pseudonyms with limited 276 linkability, since the user can always create a lot of them. 278 2. Could there be more advice for protocol developers and 279 implementers to improve anonymity? (Besides the ones in 280 Section 5.) 282 7. Security Considerations 284 As this draft concerns a research document, there are no security 285 considerations. 287 8. IANA Considerations 289 This document has no actions for IANA. 291 9. Research Group Information 293 The discussion list for the IRTF Human Rights Protocol Considerations 294 proposed working group is located at the e-mail address hrpc@ietf.org 295 [1]. Information on the group and information on how to subscribe to 296 the list is at https://www.irtf.org/mailman/listinfo/hrpc 298 Archives of the list can be found at: https://www.irtf.org/mail- 299 archive/web/hrpc/current/index.html 301 10. References 303 10.1. Informative References 305 [AnonTerm] 306 Pfitzmann, A. and M. Hansen, "A terminology for talking 307 about privacy by data minimization: Anonymity, 308 Unlinkability, Undetectability, Unobservability, 309 Pseudonymity, and Identity Management", 2010, 310 . 313 [Article29] 314 Article29, ., "Opinion 05/2014 on Anonymisation 315 Techniques", 2014, . 319 [EUcourt] "EUCJ Case C-70/10: Scarlet Extended SA vs. Societe belge 320 des auteurs, compositeurs et editeurs SCRL (SABAM)", 2011, 321 . 325 [MITdeano] 326 de Montjoye, Y., Hidalgo, C., Verleysen, M., and V. 327 Blondel, "Unique in the Crowd: The privacy bounds of human 328 mobility", 2013, . 331 [Pew] Rainie, L., Kiesler, S., Kang, R., and M. Madden, 332 "Anonymity, Privacy, and Security Online", 2013, 333 . 336 [Pew2] Duggan, M., "Online Harassment", 2014, 337 . 340 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 341 Text on Security Considerations", BCP 72, RFC 3552, 342 DOI 10.17487/RFC3552, July 2003, . 345 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 346 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 347 . 349 [RFC6235] Boschi, E. and B. Trammell, "IP Flow Anonymization 350 Support", RFC 6235, DOI 10.17487/RFC6235, May 2011, 351 . 353 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 354 Morris, J., Hansen, M., and R. Smith, "Privacy 355 Considerations for Internet Protocols", RFC 6973, 356 DOI 10.17487/RFC6973, July 2013, . 359 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 360 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 361 2014, . 363 [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, 364 DOI 10.17487/RFC7626, August 2015, . 367 [RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity 368 Profiles for DHCP Clients", RFC 7844, 369 DOI 10.17487/RFC7844, May 2016, . 372 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 373 and P. Hoffman, "Specification for DNS over Transport 374 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 375 2016, . 377 [torproject] 378 The Tor Project, ., "Tor Project - Anonymity Online", 379 2007, . 381 [UNHRC2015] 382 Kaye, D., "Anonymity, Privacy, and Security Online (A/ 383 HRC/29/32)", 2015, . 386 [Utexas] Narayanan, A. and V. Shmatikov, "Robust De-anonymization 387 of Large Sparse Datasets", 2008, 388 . 390 10.2. URIs 392 [1] mailto:hrpc@ietf.org 394 Authors' Addresses 396 Stephane Bortzmeyer 397 AFNIC 399 EMail: bortzmeyer+ietf@nic.fr 401 Niels ten Oever 402 ARTICLE 19 404 EMail: niels@article19.org