idnits 2.17.1 draft-irtf-hrpc-anonymity-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 : ---------------------------------------------------------------------------- ** 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 (February 23, 2018) is 2254 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 462 -- Looks like a reference, but probably isn't: '2' on line 464 -- Looks like a reference, but probably isn't: '3' on line 466 -- Obsolete informational reference (is this intentional?): RFC 7626 (Obsoleted by RFC 9076) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 5 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: August 27, 2018 University of Amsterdam 6 February 23, 2018 8 Anonymity, Human Rights and Internet Protocols 9 draft-irtf-hrpc-anonymity-00 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 https://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 August 27, 2018. 40 Copyright Notice 42 Copyright (c) 2018 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 (https://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 4.3. Selective use . . . . . . . . . . . . . . . . . . . . . . 6 64 4.4. User analysis . . . . . . . . . . . . . . . . . . . . . . 6 65 5. Practical advices . . . . . . . . . . . . . . . . . . . . . . 6 66 5.1. Protocol developers . . . . . . . . . . . . . . . . . . . 6 67 5.2. Protocol implementors . . . . . . . . . . . . . . . . . . 7 68 6. Open Questions . . . . . . . . . . . . . . . . . . . . . . . 7 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 70 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 71 9. Research Group Information . . . . . . . . . . . . . . . . . 8 72 10. Objections against anonymity . . . . . . . . . . . . . . . . 8 73 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 11.1. Informative References . . . . . . . . . . . . . . . . . 8 75 11.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 78 1. Introduction 80 There seems to be a clear need for anonymity online in an environment 81 where harassment on the Internet is on the increase [Pew2] and the UN 82 Special Rapporteur for Freedom of Expression calls anonymity 83 'necessary for the exercise of the right to freedom of opinion and 84 expression in the digital age' [UNHRC2015]. 86 Nonetheless anonymity is not getting much discussion at the IETF, 87 providing anonymity does not seem a (semi-)objective for many 88 protocols, even though several documents contribute to improving 89 anonymity such as [RFC7258], [RFC7626], [RFC7858]. 91 There are initiatives on the Internet to improve end users anonymity, 92 most notably [torproject], but these initiatives rely on adding 93 encryption in the application layer. 95 This document aims to break down the different meanings and 96 implications of anonymity on a mediated computer network and to see 97 whether (some parts of) anonymity should be taken into consideration 98 in protocol development. 100 2. Vocabulary Used 102 Concepts in this draft currently strongly hinges on [AnonTerm] 104 Anonymity A state of an individual in which an observer or attacker 105 cannot identify the individual within a set of other individuals 106 (the anonymity set). [RFC6973] 108 Linkability Linkability of two or more items of interest (IOIs - 109 Items Of Interest, e.g., subjects, messages, actions, ...) from an 110 attacker's perspective means that within the system (comprising 111 these and possibly other items), the attacker can sufficiently 112 distinguish whether these IOIs are related or not. [AnonTerm] 114 Official identity Government-issued identity, as written on ID cards 115 and passports. We don't use terms like "real names" since a 116 choosen pseudonym, for instance, is not less real than a identity 117 given at birth. 119 Pseudonymity Derived from pseudonym, a persistent identity which is 120 not the same as the entity's given (or official) name. For all 121 IETF protocols, pseudonimity is a given: protocols don't care 122 whether the identity is an official one or not. Even if the 123 protocol allows to use official identities (for instance in the 124 From: header of an Internet email), it does not require it. But 125 it should be noted that, if the user cannot create new pseudonyms 126 easily, pseudonyms suffer from linkability. Unlinkability depends 127 on this ability to create new pseudonyms gratis and at will (good 128 examples are SSH keys or Bitcoin addresses). Easy creation will 129 allow to have one pseudonym per use, thus defeating linkability. 131 Unlinkability Unlinkability of two or more items of interest (IOIs, 132 e.g., subjects, messages, actions, ...) from an attacker's 133 perspective means that within the system (comprising these and 134 possibly other items), the attacker cannot sufficiently 135 distinguish whether these IOIs are related or not. [AnonTerm] 137 Undetectability The impossibility of being noticed or discovered 139 Undetectability of an item of interest (IOI) from an attacker's 140 perspective means that the attacker cannot sufficiently 141 distinguish whether it exists or not [AnonTerm] 143 Unobservability 144 Unobservability of an item of interest (IOI) means: 145 undetectability of the IOI against all subjects uninvolved in it 146 and 148 anonymity of the subject(s) involved in the IOI even against the 149 other subject(s) involved in that IOI. [AnonTerm] 151 It should be noted that the word "anonymity" is both very loaded 152 politically (witness all the headlines about the "darknet") and 153 poorly understood. Most texts talking about anonymity actually refer 154 to pseudonymity (for instance, when people say that "Bitcoin is 155 anonymous"). This confusion is even in the example given in 156 [RFC4949] definition of anonymity. 158 Anonymity is strongly linked to unlinkability: if your actions are 159 linkable, it suffices that one of them is tied to your identity, and 160 anonymity is over. 162 It should be noted that anonymity is not binary: there have been 163 these recent years a lot of progress of desanonymisation techniques 164 (see also [GDPR], article 26). Data is never fully "anonymous", it 165 is only more or less anonymous. [RFC6235] [MITdeano] [Utexas] 166 [Article29] 168 3. Should protocols promote anonymity? 170 The amount of data that is generated by and about individuals is 171 growing exponentially. This can be attributed to the fact that an 172 ever increasing number of actions is digitally mediated, and the 173 increase of connected sensors in the every day environment. Even 174 though these two causes do not fully fall within the scope of the 175 IETF, there is a significant part of these two examples that do. 177 TODO add here more examples of the need to anonymity 179 With the increase of data there is also an increasing ability for 180 third parties to analyze human behaviour. It should be noted that 181 any data that could identify an individual is personally identifiable 182 information (PII). This means that information which can be used to 183 distinguish an indivual from other individuals can be considered as 184 personally identiable information. The access and control of 185 personally identifiable information by a third party is a (potential) 186 liability for both the third party and the individual. This 187 liability could for example translate into a physical risk for the 188 individual or into a legal risk for the third party under information 189 security and privacy laws. 191 Some network operators argue that without the opportunity to 192 persistently identify individual users it becomes harder to thwart 193 attacks and troubleshoot network issues. Whereas identification 194 might be helpful to address issues in some cases, it poses an 195 inherent threat to the anonymity of users. Not protecting the 196 anonymity of users leads to a deterioration of the right to privacy, 197 and the right to freedom of opinion and expression. There can be 198 limitations the right to privacy and freedom of expression, but these 199 should always be provided by law and necessary and proportionate to 200 achieve one of a handful of legitimate objectives. It is clear that 201 anonymity may make system and network administration different. To 202 quote [RFC7824], "Those properties (stable and trackable IP 203 addresses, derived from static identifiers) are convenient for system 204 administrators". Here, there is a clear and fundamental tussle 205 between the protection of the users and the ability of the system and 206 network administrator to continue their work in the same way. 208 Anonymity will always be a balancing act between user protection 209 (which requires a high level of anonymity) and other requirments for 210 operations and research, such as routing information. Anonymity is 211 by no means achieved by default in an online environment, nor has it 212 been a strong consideration in protocol development in the 213 development of the Internet. Increasing anonymity in the digital 214 environment is not an easy task, exactly because the ubiquity of data 215 that is generated and stored. But exactly the fact that we generate 216 so much data urges us to address this issue. 218 4. Example of use cases 220 4.1. Simultaneous use 222 One user may use concurrently several identities, mixing them in 223 operations, while wanting to keep them distinct. The protocol and 224 its implementations should not preclude this use. 226 4.2. Successive use 228 One user may switch from one identity to another. In that case, it 229 must be doable without a "bleedover" from the old identity to the new 230 one. 232 One of the reasons to switch identities might be to make the 233 relationship between this identity and another one (for instance the 234 official one) more difficult. The longer you use a pseudonym, the 235 more clues you give to someone who tries to unveil pseudonymity. 237 4.3. Selective use 239 A user might want to retain their anonymity to certain actors / 240 protocols, but identified to others. Also, she may also wish to be 241 identified for some operations but not always. 243 4.4. User analysis 245 A user might want to understand which other actors might 246 (potentially) have which level of information about them. This 247 conflicts of course with privacy because the user has to reveal who 248 he is. Example: if a domain name registry does not publish the name 249 of a registrant, the registrant cannot check if the person who did 250 the registration indicated the name of their client, or their own 251 name. 253 5. Practical advices 255 5.1. Protocol developers 257 First, the protocol should avoid to have mandatory persistent 258 identifiers. 260 Even without persistent identifiers, anonymity could be broken by 261 examining the patterns of access. If an user visits each morning the 262 three same Web sites, always in the same order, it will be easy to 263 identify them even without persistent identifier. Protocol designers 264 should therefore ask themselves if patterns are easily visible, or 265 obfuscated in some way. 267 If the protocol collects data and distributes it (see [RFC6235]), 268 "anonymizing" the data is often suggested but it is notoriously hard. 269 Do not think that just dropping the last byte of an IP address 270 "anonymizes" data. 272 Pay attention to the fact that Internet actors do not all see the 273 same thing. Consider the anonymity of the user with respect to: 275 - local network operator 277 - other networks you connect to 279 - your communications peer on the other end of the pipe 281 - intermediaries ([RFC6973]) 283 - enablers ([RFC6973]) 284 - someone who is in several roles, for instance a big state 285 surveillance agency 287 5.2. Protocol implementors 289 Avoid adding options or configurations that create or might lead to 290 patterns or regularities that are not explicitely required by the 291 protocol. 293 An example is DHCP where sending a persistent identifier as the 294 client name was not mandatory but, in practice, done by many 295 implementations, before [RFC7844]. 297 If an implementation allows for identity management, there should be 298 a clear barrier between the identities to ensure that they cannot 299 (easily) be associated with each other. 301 If there are anonymization option for the protocol, these should be 302 enabled by default. 304 6. Open Questions 306 While analyzing protocols for their impact on users anonymity, would 307 it make sense to ask the following questions: 309 1. How does the protocol impact pseudonymity? If the protocol 310 limits the creation of new pseudonyms, it can limit their 311 usefulness to "hide" an user's identity. For instance, IP 312 addresses are pseudonyms but, since they are not under end 313 users's control, they have strong linkability. That's why they 314 are rightly regarded as personal identifiers [EUcourt]. On the 315 other hand, Bitcoin addresses are pseudonyms with limited 316 linkability, since the user can always create a lot of them. 318 2. Could there be more advice for protocol developers and 319 implementers to improve anonymity? (Besides the ones in 320 Section 5.) 322 7. Security Considerations 324 As this draft concerns a research document, there are no security 325 considerations. 327 8. IANA Considerations 329 This document has no actions for IANA. 331 9. Research Group Information 333 The discussion list for the IRTF Human Rights Protocol Considerations 334 proposed working group is located at the e-mail address hrpc@ietf.org 335 [1]. Information on the group and information on how to subscribe to 336 the list is at https://www.irtf.org/mailman/listinfo/hrpc [2] 338 Archives of the list can be found at: https://www.irtf.org/mail- 339 archive/web/hrpc/current/index.html [3] 341 10. Objections against anonymity 343 TODO: should be turned into an appendix. This draft is about how to 344 allow anonymity, not about how to fight it. 346 For a long time, there have been objections against anonymity. This 347 document won't attempt to rebuke them all, since it is concerned 348 about how to ensure that protocols allow anonymity. But it is 349 interesting to keep in mind that protocols never forbid anonymity. 350 If smeones want his or her actions to be trackable, and under her or 351 his official name, they can do so, by adding this information to 352 their messages. In the same way, people are free not to engage with 353 anonymous entities, in the same way that a SIP use, for instance, is 354 free not to pick up a call if it comes from 355 sip:anonymous@anonymous.invalid. This document is concerned about 356 enabling anonymity, not about mandating it. 358 11. References 360 11.1. Informative References 362 [AnonTerm] 363 Pfitzmann, A. and M. Hansen, "A terminology for talking 364 about privacy by data minimization: Anonymity, 365 Unlinkability, Undetectability, Unobservability, 366 Pseudonymity, and Identity Management", 2010, 367 . 370 [Article29] 371 Article29, ., "Opinion 05/2014 on Anonymisation 372 Techniques", 2014, . 376 [EUcourt] "EUCJ Case C-70/10: Scarlet Extended SA vs. Societe belge 377 des auteurs, compositeurs et editeurs SCRL (SABAM)", 2011, 378 . 382 [GDPR] European Parliament and Council, ., "REGULATION (EU) 383 2016/679 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL on 384 the protection of natural persons with regard to the 385 processing of personal data and on the free movement of 386 such data, and repealing Directive 95/46/EC (General Data 387 Protection Regulation)", 2016, . 390 [MITdeano] 391 de Montjoye, Y., Hidalgo, C., Verleysen, M., and V. 392 Blondel, "Unique in the Crowd: The privacy bounds of human 393 mobility", 2013, 394 . 396 [Pew] Rainie, L., Kiesler, S., Kang, R., and M. Madden, 397 "Anonymity, Privacy, and Security Online", 2013, 398 . 401 [Pew2] Duggan, M., "Online Harassment", 2014, 402 . 405 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 406 Text on Security Considerations", BCP 72, RFC 3552, 407 DOI 10.17487/RFC3552, July 2003, 408 . 410 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 411 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 412 . 414 [RFC6235] Boschi, E. and B. Trammell, "IP Flow Anonymization 415 Support", RFC 6235, DOI 10.17487/RFC6235, May 2011, 416 . 418 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 419 Morris, J., Hansen, M., and R. Smith, "Privacy 420 Considerations for Internet Protocols", RFC 6973, 421 DOI 10.17487/RFC6973, July 2013, 422 . 424 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 425 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 426 2014, . 428 [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, 429 DOI 10.17487/RFC7626, August 2015, 430 . 432 [RFC7824] Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy 433 Considerations for DHCPv6", RFC 7824, 434 DOI 10.17487/RFC7824, May 2016, 435 . 437 [RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity 438 Profiles for DHCP Clients", RFC 7844, 439 DOI 10.17487/RFC7844, May 2016, 440 . 442 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 443 and P. Hoffman, "Specification for DNS over Transport 444 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 445 2016, . 447 [torproject] 448 The Tor Project, ., "Tor Project - Anonymity Online", 449 2007, . 451 [UNHRC2015] 452 Kaye, D., "Anonymity, Privacy, and Security Online (A/ 453 HRC/29/32)", 2015, . 456 [Utexas] Narayanan, A. and V. Shmatikov, "Robust De-anonymization 457 of Large Sparse Datasets", 2008, 458 . 460 11.2. URIs 462 [1] mailto:hrpc@ietf.org 464 [2] https://www.irtf.org/mailman/listinfo/hrpc 466 [3] https://www.irtf.org/mail-archive/web/hrpc/current/index.html 468 Authors' Addresses 470 Stephane Bortzmeyer 471 AFNIC 473 EMail: bortzmeyer+ietf@nic.fr 475 Niels ten Oever 476 University of Amsterdam 478 EMail: mail@nielstenoever.net