idnits 2.17.1 draft-iab-privacy-considerations-02.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 12, 2012) is 4427 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-01) exists of draft-iab-privacy-terminology-00 -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Cooper 3 Internet-Draft CDT 4 Intended status: Informational H. Tschofenig 5 Expires: September 13, 2012 Nokia Siemens Networks 6 B. Aboba 7 Microsoft Corporation 8 J. Peterson 9 NeuStar, Inc. 10 J. Morris 11 March 12, 2012 13 Privacy Considerations for Internet Protocols 14 draft-iab-privacy-considerations-02.txt 16 Abstract 18 This document offers guidance for developing privacy considerations 19 for IETF documents and aims to make protocol designers aware of 20 privacy-related design choices. 22 Discussion of this document is taking place on the IETF Privacy 23 Discussion mailing list (see 24 https://www.ietf.org/mailman/listinfo/ietf-privacy). 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 13, 2012. 43 Copyright Notice 45 Copyright (c) 2012 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Internet Privacy Threat Model . . . . . . . . . . . . . . . . 5 63 3.1. Communications Model . . . . . . . . . . . . . . . . . . . 5 64 3.2. Privacy Threats . . . . . . . . . . . . . . . . . . . . . 6 65 3.2.1. Combined Security-Privacy Threats . . . . . . . . . . 6 66 3.2.2. Privacy-Specific Threats . . . . . . . . . . . . . . . 8 67 4. Internet Privacy Goals . . . . . . . . . . . . . . . . . . . . 11 68 4.1. Data Minimization . . . . . . . . . . . . . . . . . . . . 11 69 4.2. User Participation . . . . . . . . . . . . . . . . . . . . 12 70 4.3. Accountability . . . . . . . . . . . . . . . . . . . . . . 12 71 4.4. Security . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 5. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 5.2. Data Minimization . . . . . . . . . . . . . . . . . . . . 13 75 5.3. User Participation . . . . . . . . . . . . . . . . . . . . 14 76 5.4. Accountability . . . . . . . . . . . . . . . . . . . . . . 15 77 5.5. Security . . . . . . . . . . . . . . . . . . . . . . . . . 15 78 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 79 7. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 81 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 82 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 83 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 84 11.1. Normative References . . . . . . . . . . . . . . . . . . . 23 85 11.2. Informative References . . . . . . . . . . . . . . . . . . 23 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 88 1. Introduction 90 [RFC3552] provides detailed guidance to protocol designers about both 91 how to consider security as part of protocol design and how to inform 92 readers of IETF documents about security issues. This document 93 intends to provide a similar set of guidance for considering privacy 94 in protocol design. 96 Whether any individual document will require a specific privacy 97 considerations section will depend on the document's content. 98 Documents whose entire focus is privacy may not merit a separate 99 section (for example, [RFC3325]). For certain specifications, 100 privacy considerations are a subset of security considerations and 101 can be discussed explicitly in the security considerations section. 102 The guidance provided here can and should be used to assess the 103 privacy considerations of protocol, architectural, and operational 104 specifications and to decide whether those considerations are to be 105 documented in a stand-alone section, within the security 106 considerations section, or throughout the document. 108 Privacy is a complicated concept with a rich history that spans many 109 disciplines. Many sets of privacy principles and privacy design 110 frameworks have been developed in different forums over the years. 111 These include the Fair Information Practices (FIPs), a baseline set 112 of privacy protections pertaining to the collection and use of data 113 about individuals (see [OECD] for one example), and the Privacy by 114 Design concept, which provides high-level privacy guidance for 115 systems design (see [PbD] for one example). The guidance provided in 116 this document is inspired by this prior work, but it aims to be more 117 concrete, pointing protocol designers to specific engineering choices 118 that can impact the privacy of the individuals that make use of 119 Internet protocols. 121 Privacy as a legal concept is understood differently in different 122 jurisdictions. The guidance provided in this document is generic and 123 can be used to inform the design of any protocol to be used anywhere 124 in the world, without reference to specific legal frameworks. 126 This document is organized as follows. Section 2 describes the 127 extent to which the guidance offered is applicable within the IETF. 128 Section 3 discusses threats to privacy as they apply to Internet 129 protocols. Section 4 outlines privacy goals. Section 5 provides the 130 guidelines for analyzing and documenting privacy considerations 131 within IETF specifications. Section 6 examines the privacy 132 characteristics of an IETF protocol to demonstrate the use of the 133 guidance framework. Section 7 provides a concise glossary of terms 134 used in this document, with a more complete discussion of some of the 135 terms available in [I-D.iab-privacy-terminology]. 137 2. Scope 139 The core function of IETF activity is building protocols. Internet 140 protocols are often built flexibly, making them useful in a variety 141 of architectures, contexts, and deployment scenarios without 142 requiring significant interdependency between disparately designed 143 components. Although some protocols assume particular architectures 144 at design time, it is not uncommon for architectural frameworks to 145 develop later, after implementations exist and have been deployed in 146 combination with other protocols or components to form complete 147 systems. 149 As a consequence, the extent to which protocol designers can foresee 150 all of the privacy implications of a particular protocol at design 151 time is significantly limited. An individual protocol may be 152 relatively benign on its own, but when deployed within a larger 153 system or used in a way not envisioned at design time, its use may 154 create new privacy risks. The guidelines in Section 5 ask protocol 155 designers to consider how their protocols are expected to interact 156 with systems and information that exist outside the protocol bounds, 157 but not to imagine every possible deployment scenario. 159 Furthermore, in many cases the privacy properties of a system are 160 dependent upon API specifics, internal application functionality, 161 database structure, local policy, and other details that are specific 162 to particular instantiations and generally outside the scope of the 163 work conducted in the IETF. The guidance provided here may be useful 164 in making choices about those details, but its primary aim is to 165 assist with the design, implementation, and operation of protocols. 166 Privacy issues, even those related to protocol development, go beyond 167 the technical guidance discussed herein. 169 As an example, consider HTTP [RFC2616], which was designed to allow 170 the exchange of arbitrary data. A complete analysis of the privacy 171 considerations for uses of HTTP might include what type of data is 172 exchanged, how this data is stored, and how it is processed. Hence 173 the analysis for an individual's static personal web page would be 174 different than the use of HTTP for exchanging health records. A 175 protocol designer working on HTTP extensions (such as WebDAV 176 [RFC4918]) is not expected to describe the privacy risks derived from 177 all possible usage scenarios, but rather the privacy properties 178 specific to the extensions and any particular uses of the extensions 179 that are expected and foreseen at design time. 181 3. Internet Privacy Threat Model 183 Privacy harms come in a number of forms, including harms to financial 184 standing, reputation, solitude, autonomy, and safety. A victim of 185 identity theft or blackmail, for example, may suffer a financial loss 186 as a result. Reputational harm can occur when disclosure of 187 information about an individual, whether true or false, subjects that 188 individual to stigma, embarrassment, or loss of personal dignity. 189 Intrusion or interruption of an individual's life or activities can 190 harm the individual's ability to be left alone. When individuals or 191 their activities are monitored, exposed, or at risk of exposure, 192 those individuals may be stifled from expressing themselves, 193 associating with others, and generally conducting their lives freely. 194 In cases where such monitoring is for the purpose of stalking or 195 violence, it can put individuals in physical danger. 197 This section lists common privacy threats (drawing liberally from 198 [Solove]), showing how each of them may cause individuals to incur 199 privacy harms and providing examples of how these threats can exist 200 on the Internet. 202 3.1. Communications Model 204 To understand attacks in the privacy-harm sense, it is helpful to 205 consider the overall communication architecture and different actors' 206 roles within it. Consider a protocol element that initiates 207 communication with some recipient (an "initiator"). Privacy analysis 208 is most relevant for protocols with use cases in which the initiator 209 acts on behalf of a natural person (or different people at different 210 times). It is this natural person -- the data subject -- whose 211 privacy is potentially threatened. 213 Communications may be direct between the initiator and the recipient, 214 or they may involve an intermediary (such as a proxy or cache) that 215 is necessary for the two parties to communicate. In some cases this 216 intermediary stays in the communication path for the entire duration 217 of the communication and sometimes it is only used for communication 218 establishment, for either inbound or outbound communication. In rare 219 cases there may be a series of intermediaries that are traversed. 221 Some communications tasks require multiple protocol interactions with 222 different entities. For example, a request to an HTTP server may be 223 preceded by an interaction between the initiator and an 224 Authentication, Authorization, and Accounting (AAA) server or DNS 225 resolver. In this case, the HTTP server is the recipient and the 226 other entities are enablers of the initiator-to-recipient 227 communication. Similarly, a single communication with the recipient 228 my generate further protocol interactions between either the 229 initiator or the recipient and other entities. For example, an HTTP 230 request might trigger interactions with an authentication server or 231 with other resource servers. 233 As a general matter, recipients, intermediaries, and enablers are 234 usually assumed to be authorized to receive and handle data from 235 initiators. As [RFC3552] explains, "we assume that the end-systems 236 engaging in a protocol exchange have not themselves been 237 compromised." 239 Although they may not generally be considered as attackers, 240 recipients, intermediaires, and enablers may all pose privacy threats 241 (depending on the context) because they are able to observe and 242 collect privacy-relevant data. These entities are collectively 243 described below as "observers" to distinguish them from traditional 244 attackers. From a privacy perspective, one important type of 245 attacker is an eavesdropper: an entity that passively observes the 246 initiator's communications without the initiator's knowledge or 247 authorization. 249 The threat descriptions in the next section explain how observers and 250 attackers might act to harm data subjects' privacy. Different kinds 251 of attacks may be feasible at different points in the communications 252 path. For example, an observer could mount surveillance or 253 identification attacks between the initiator and intermediary, or 254 instead could surveil an enabler (e.g., by observing DNS queries from 255 the initiator). 257 3.2. Privacy Threats 259 Some privacy threats are already considered in IETF protocols as a 260 matter of routine security analysis. Others are more pure privacy 261 threats that existing security considerations do not usually address. 262 The threats described here are divided into those that may also be 263 considered security threats and those that are primarily privacy 264 threats. 266 Note that an individual's knowledge and authorization of the 267 practices described below can greatly affect the extent to which they 268 threaten privacy. If a data subject authorizes surveillance of his 269 own activities, for example, the harms associated with it may be 270 significantly mitigated. 272 3.2.1. Combined Security-Privacy Threats 273 3.2.1.1. Surveillance 275 Surveillance is the observation or monitoring of an individual's 276 communications or activities. The effects of surveillance on the 277 individual can range from anxiety and discomfort to behavioral 278 changes such as inhibition and self-censorship to the perpetration of 279 violence against the individual. The individual need not be aware of 280 the surveillance for it to impact privacy -- the possibility of 281 surveillance may be enough to harm individual autonomy. 283 Surveillance can be conducted by observers or eavesdroppers at any 284 point along the communications path. Confidentiality protections (as 285 discussed in [RFC3552] Section 3) are necessary to prevent 286 surveillance of the content of communications. To prevent traffic 287 analysis or other surveillance of communications patterns, other 288 measures may be necessary, such as [Tor]. 290 3.2.1.2. Stored Data Compromise 292 End systems that do not take adequate measures to secure stored data 293 from unauthorized or inappropriate access expose individuals to 294 potential financial, reputational, or physical harm. 296 By and large, protecting against stored data compromise is outside 297 the scope of IETF protocols. However, a number of common protocol 298 functions -- key management, access control, or operational logging, 299 for example -- require the storage of data about initiators of 300 communications. When requiring or recommending that information 301 about initiators or their communications be stored or logged by end 302 systems (see, e.g., RFC 6302), it is important to recognize the 303 potential for that information to be compromised and for that 304 potential to be weighed against the benefits of data storage. Any 305 recipient, intermediary, or enabler that stores data may be 306 vulnerable to compromise. 308 3.2.1.3. Intrusion 310 Intrusion consists of invasive acts that disturb or interrupt one's 311 life or activities. Intrusion can thwart individuals' desires to be 312 let alone, sap their time or attention, or interrupt their 313 activities. 315 Unsolicited mail and denial-of-service attacks are the most common 316 types of intrusion on the Internet. Intrusion can be perpetrated by 317 any attacker that is capable of sending unwanted traffic to the 318 initiator. 320 3.2.2. Privacy-Specific Threats 322 3.2.2.1. Correlation 324 Correlation is the combination of various pieces of information about 325 an individual. Correlation can defy people's expectations of the 326 limits of what others know about them. It can increase the power 327 that those doing the correlating have over individuals as well as 328 correlators' ability to pass judgment, threatening individual 329 autonomy and reputation. 331 Correlation is closely related to identification. Internet protocols 332 can facilitate correlation by allowing data subjects' activities to 333 be tracked and combined over time. The use of persistent or 334 infrequently refreshed identifiers at any layer of the stack can 335 facilitate correlation. For example, an initiator's persistent use 336 of the same device ID, certificate, or email address across multiple 337 interactions could allow recipients to correlate all of the 338 initiator's communications over time. 340 In theory any observer or attacker that receives an initiator's 341 communications can engage in correlation. The extent of the 342 potential for correlation will depend on what data the entity 343 receives from the initiator and has access to otherwise. Often, 344 intermediaries only require a small amount of information for message 345 routing and/or security. In theory, protocol mechanisms could ensure 346 that end-to-end information is not made accessible to these entities, 347 but in practice the difficulty of deploying end-to-end security 348 procedures, additional messaging or computational overhead, and other 349 business or legal requirements often slow or prevent the deployment 350 of end-to-end security mechanisms, giving intermediaries greater 351 exposure to initiators' data than is strictly necessary. 353 3.2.2.2. Identification 355 Identification is the linking of information to a particular 356 individual. In some contexts it is perfectly legitimate to identify 357 individuals, whereas in others identification may potentially stifle 358 individuals' activities or expression by inhibiting their ability to 359 be anonymous or pseudonymous. Identification also makes it easier 360 for individuals to be explicitly controlled by others (e.g., 361 governments). 363 Many protocol identifiers, such as those used in SIP or XMPP, may 364 allow for the direct identification of data subjects. Protocol 365 identifiers may also contribute indirectly to identification via 366 correlation. For example, a web site that does not directly 367 authenticate users may be able to match its HTTP header logs with 368 logs from another site that does authenticate users, rendering users 369 on the first site identifiable. 371 As with correlation, any observer or attacker may be able to engage 372 in identification depending on the information about the initiator 373 that is available via the protocol mechanism or other channels. 375 3.2.2.3. Secondary Use 377 Secondary use is the use of collected information without the data 378 subject's consent for a purpose different from that for which the 379 information was collected. Secondary use may violate people's 380 expectations or desires. The potential for secondary use can 381 generate uncertainty over how one's information will be used in the 382 future, potentially discouraging information exchange in the first 383 place. 385 One example of secondary use would be a network access server that 386 uses an initiator's access requests to track the initiator's 387 location. Any observer or attacker could potentially make unwanted 388 secondary uses of initiators' data. 390 3.2.2.4. Disclosure 392 Disclosure is the revelation of truthful information about a person 393 that affects the way others judge the person. Disclosure can violate 394 people's expectations of the confidentiality of the data they share. 395 The threat of disclosure may deter people from engaging in certain 396 activities for fear of reputational harm. 398 Any observer or attacker that receives data about an initiator may 399 choose to engage in disclosure. In most cases, there is nothing done 400 at the protocol level to influence or limit disclosure, although 401 there are some exceptions. For example, the GEOPRIV architecture 402 [RFC6280] provides a way for users to express a preference that their 403 location information not be disclosed beyond the intended recipient. 405 3.2.2.5. Exclusion 407 Exclusion is the failure to allow the data subject to know about the 408 data that others have about him or her and to participate in its 409 handling and use. Exclusion reduces accountability on the part of 410 entities that maintain information about people and creates a sense 411 of vulnerability about individuals' ability to control how 412 information about them is collected and used. 414 The most common way for Internet protocols to be involved in limiting 415 exclusion is through access control mechanisms. The presence 416 architecture developed in the IETF is a good example where data 417 subjects are included in the control of information about them. 418 Using a rules expression language (e.g., Presence Authorization Rules 419 [RFC5025]), presence clients can authorize the specific conditions 420 under which their presence information may be shared. 422 Exclusion is primarily considered problematic when the recipient 423 fails to involve the initiator in decisions about data collection, 424 handling, and use. Eavesdroppers engage in exclusion by their very 425 nature since their data collection and handling practices are covert. 427 4. Internet Privacy Goals 429 Privacy is notoriously difficult to measure and quantify. The extent 430 to which a particular protocol, system, or architecture "protects" or 431 "enhances" privacy is dependent on a large number of factors relating 432 to its design, use, and potential misuse. However, there are certain 433 widely recognized privacy properties against which designs may be 434 assessed for their potential to impact privacy. This section adapts 435 these properties into four privacy goals for Internet protocols: (1) 436 data minimization, (2) user participation, (3) accountability, and 437 (4) security. 439 4.1. Data Minimization 441 Data minimization refers to collecting, using, and storing the 442 minimal data necessary to perform a task. The less data about data 443 subjects that gets exchanged in the first place, the lower the 444 chances of that data being used for privacy invasion. 446 Data minimization is comprised of a number of mutually exclusive sub- 447 goals: 449 o Use limitation: Limiting the uses to which data is put helps 450 contain the spread of data to third parties and protects against 451 uses that may violate data subjects' expectations. 453 o Retention limitation: Limiting the duration of data storage 454 reduces the risk of stored data compromise. 456 o Identifiability limitation: Minimization pertains not only to the 457 amount of data exchanged, but also the extent to which it can be 458 used to identify data subjects. Reducing the identifiability of 459 data by using pseudonymous or anonymous identifiers helps to 460 weaken the link between a data subject and his or her 461 communications. Refreshing or recycling identifiers reduces the 462 possibility that multiple protocol interactions or communications 463 can be correlated back to the same data subject. 465 o Sensitivity limitation: The sensitivity of data is another 466 property that can be minimized. For example, the street address 467 of a building that an individual visits may be considered to be a 468 more sensitive piece of information than the city and postal code 469 in which the building is located. Collecting, using, and storing 470 less sensitive data may mitigate the damage caused by secondary 471 use, disclosure, stored data compromise, and correlation. 473 4.2. User Participation 475 As explained in Section 3.2.2.5, data collection and use that happens 476 "in secret," without the data subject's knowledge, is apt to violate 477 the subject's expectation of privacy and may create incentives for 478 misuse of data. As a result, privacy regimes tend to include 479 provisions to support informing data subjects about data collection 480 and use and involving them in decisions about the treatment of their 481 data. In an engineering context, supporting the goal of user 482 participation usually means providing ways for users to control the 483 data that is shared about them. 485 4.3. Accountability 487 An entity that collects, uses, or stores data can undergird its 488 commitments to the other privacy goals by providing mechanisms by 489 which data subjects and third parties can hold the entity accountable 490 for those commitments. These mechanisms usually allow for 491 verification of what data is collected or stored and with whom it is 492 shared, again helping to mitigate the threat of exclusion. 494 4.4. Security 496 Keeping data secure at rest and in transit is another important 497 component of privacy protection. As they are described in [RFC3552] 498 Section 2, a number of security goals also serve to enhance privacy: 500 o Confidentiality: Keeping data secret from unintended listeners. 502 o Peer entity authentication: Ensuring that the endpoint of a 503 communication is the one that is intended (in support of 504 maintaining confidentiality). 506 o Unauthorized usage: Limiting data access to only those users who 507 are authorized, helping to prevent stored data compromise. 509 o Inappropriate usage: Limiting how authorized users can use data. 510 (Note that this goal also falls within data minimization.) 512 5. Guidelines 514 This section provides guidance for document authors in the form of a 515 questionnaire about a protocol being designed. The questionnaire may 516 be useful at any point in the design process, particularly after 517 document authors have developed a high-level protocol model as 518 described in [RFC4101]. 520 Note that the guidance does not recommend specific practices. The 521 range of protocols developed in the IETF is too broad to make 522 recommendations about particular uses of data or how privacy might be 523 balanced against other design goals. However, by carefully 524 considering the answers to each question, document authors should be 525 able to produce a comprehensive analysis that can serve as the basis 526 for discussion of whether the protocol adequately protects against 527 privacy threats. 529 The framework is divided into four sections that address each of the 530 goals from Section 4, plus a general section. Security is not fully 531 elaborated since substantial guidance already exists in [RFC3552]. 533 5.1. General 535 a. Trade-offs. Does the protocol make trade-offs between privacy 536 and usability, privacy and efficiency, privacy and 537 implementability, or privacy and other design goals? Describe the 538 trade-offs and the rationale for the design chosen. 540 5.2. Data Minimization 542 a. Identifiers. What identifiers does the protocol use for 543 distinguishing initiators of communications? Does the protocol 544 use identifiers that allow different protocol interactions to be 545 correlated? 547 b. Personal data. What information does the protocol expose 548 about data subjects and/or their devices (other than the 549 identifiers discussed in (a))? To what extent is this information 550 linked to the identities of data subjects? How does the protocol 551 combine personal data with the identifiers discussed in (a)? 553 c. Observers. Which information discussed in (a) and (b) is 554 exposed to each other protocol entity (i.e., recipients, 555 intermediaries, and enablers)? Are there ways for protocol 556 implementers to choose to limit the information shared with each 557 entity? Are there operational controls available to limit the 558 information shared with each entity? 559 d. Fingerprinting. In many cases the specific ordering and/or 560 occurrences of information elements in a protocol allow users, 561 devices, or software using the protocol to be fingerprinted. Is 562 this protocol vulnerable to fingerprinting? If so, how? 564 e. Persistence of identifiers. What assumptions are made in the 565 protocol design about the lifetime of the identifiers discussed in 566 (a)? Does the protocol allow implementers or users to delete or 567 recycle identifiers? How often does the specification recommend 568 to delete or recycle identifiers by default? 570 f. Correlation. Are there expected ways that information exposed 571 by the protocol will be combined or correlated with information 572 obtained outside the protocol? How will such combination or 573 correlation facilitate fingerprinting of a user, device, or 574 application? Are there expected combinations or correlations with 575 outside data that will make users of the protocol more 576 identifiable? 578 g. Retention. Do the protocol or its anticipated uses require 579 that the information discussed in (a) or (b) be retained by 580 recipients, intermediaries, or enablers? Is the retention 581 expected to be persistent or temporary? 583 5.3. User Participation 585 a. User control. What controls or consent mechanisms does the 586 protocol define or require before personal data or identifiers are 587 shared or exposed via the protocol? If no such mechanisms are 588 specified, is it expected that control and consent will be handled 589 outside of the protocol? 591 b. Control over sharing with individual recipients. Does the 592 protocol provide ways for initiators to share different 593 information with different recipients? If not, are there 594 mechanisms that exist outside of the protocol to provide 595 initiators with such control? 597 c. Control over sharing with intermediaries. Does the protocol 598 provide ways for initiators to limit which information is shared 599 with intermediaries? If not, are there mechanisms that exist 600 outside of the protocol to provide users with such control? Is it 601 expected that users will have relationships (contractual or 602 otherwise) with intermediaries that govern the use of the 603 information? 604 d. Preference expression. Does the protocol provide ways for 605 initiators to express data subjects' preferences to recipients or 606 intermediaries with regard to the use or disclosure of their 607 personal data? 609 5.4. Accountability 611 a. Verification. If the protocol provides for user preference 612 expression, does it also define or require mechanisms that allow 613 initiators to verify that data subjects' preferences are being 614 honored? If not, are there mechanisms that exist outside of the 615 protocol that allow for verification? 617 5.5. Security 619 a. Surveillance. How do the protocol's security considerations 620 prevent surveillance, including eavesdropping and traffic analyis? 622 b. Stored data compromise. How do the protocol's security 623 considerations prevent or mitigate stored data compromise? 625 c. Intrusion. How do the protocol's security considerations 626 prevent or mitigate intrusion, including denial-of-service attacks 627 and unsolicited communications more generally? 629 6. Example 631 [To be provided in a future version once the guidance is settled.] 633 7. Glossary 635 $ Anonymity 637 The state of being anonymous. See [I-D.iab-privacy-terminology]. 639 $ Anonymous 641 A property of a data subject in which an observer or attacker 642 cannot identify the data subject within a set of other subjects 643 (the anonymity set). 645 $ Attacker 647 An entity that intentionally works against some protection goal. 649 $ Attribute 651 A property of a data subject or initiator. 653 $ Correlation 655 The combination of various pieces of information about a data 656 subject. 658 $ Data Subject 660 An identified natural person or a natural person who can be 661 identified, directly or indirectly. 663 $ Eavesdropper 665 An entity that passively observes an initiator's communications 666 without the initiator's knowledge or authorization. See 667 [RFC4949]. 669 $ Enabler 671 A protocol entity that facilitates communication between an 672 initiator and a recipient without being directly in the 673 communications path. 675 $ Fingerprint 677 A set of information elements that identifies a device, 678 application, or initiator. 680 $ Fingerprinting 682 The process of an observer or attacker partially or fully 683 identifying a device, application, or initiator based on multiple 684 information elements communicated to the observer or attacker. 685 See [EFF]. 687 $ Identifiable 689 A state in which a data subject's identity is known. 691 $ Identifiability 693 The extent to which a data subject is identifiable. See 694 [I-D.iab-privacy-terminology]. 696 $ Identifier 698 A data object that represents a specific identity of a protocol 699 entity or data subject. See [RFC4949]. 701 $ Identification 703 The linking of information to a particular data subject to infer 704 the subject's identity. 706 $ Identity 708 Any subset of a data subject's attributes that identifies the 709 subject within a given context. Data subjects usually have 710 multiple identities for use in different contexts. 712 $ Initiator 714 A protocol entity that initiates communications with a recipient. 716 $ Intermediary 718 A protocol entity that sits between the initiator and the 719 recipient and is necessary for the initiator and recipient to 720 communicate. 722 $ Item of Interest (IOI) 724 Any data item that an observer or attacker might be interested in. 725 This includes attributes, identifiers, identities, communications, 726 or actions (such as the sending or receiving of a communication). 727 See [I-D.iab-privacy-terminology]. 729 $ Observer 731 An entity that is authorized to receive and handle data from an 732 initiator and thereby is able to observe and collect information, 733 potentially posing privacy threats depending on the context. 734 Recipients, intermediaries, and enablers can all be observers. 736 $ Personal Data 738 Any information relating to a data subject. 740 $ (Protocol) Interaction 742 A unit of communication within a particular protocol. A single 743 interaction may be compromised of a single message between an 744 initiator and recipient or multiple messages, depending on the 745 protocol. 747 $ Pseudonym 749 An identifier of a data subject other than the subject's real 750 name. 752 $ Pseudonymity 754 The state of being pseudonymous. See 755 [I-D.iab-privacy-terminology]. 757 $ Pseudonymous 759 A property of a data subject in which the subject is identified by 760 a pseudonym. 762 $ Recipient 764 A protocol entity that recieves communications from an initiator. 766 $ Traffic Analysis 768 The inference of information from observation of traffic flows 769 (presence, absence, amount, direction, and frequency). See 770 [RFC4949]. 772 8. Security Considerations 774 This document describes privacy aspects that protocol designers 775 should consider in addition to regular security analysis. 777 9. IANA Considerations 779 This document does not require actions by IANA. 781 10. Acknowledgements 783 We would like to thank the participants for the feedback they 784 provided during the December 2010 Internet Privacy workshop co- 785 organized by MIT, ISOC, W3C and the IAB. 787 11. References 789 11.1. Normative References 791 [I-D.iab-privacy-terminology] 792 Hansen, M., Tschofenig, H., and R. Smith, "Privacy 793 Terminology", draft-iab-privacy-terminology-00 (work in 794 progress), January 2012. 796 11.2. Informative References 798 [EFF] Electronic Frontier Foundation, "Panopticlick", 2011. 800 [OECD] Organization for Economic Co-operation and Development, 801 "OECD Guidelines on the Protection of Privacy and 802 Transborder Flows of Personal Data", available at 803 (September 2010) , http://www.oecd.org/EN/document/ 804 0,,EN-document-0-nodirectorate-no-24-10255-0,00.html, 805 1980. 807 [PbD] Office of the Information and Privacy Commissioner, 808 Ontario, Canada, "Privacy by Design", 2011. 810 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 811 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 812 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 814 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 815 Extensions to the Session Initiation Protocol (SIP) for 816 Asserted Identity within Trusted Networks", RFC 3325, 817 November 2002. 819 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 820 Text on Security Considerations", BCP 72, RFC 3552, 821 July 2003. 823 [RFC4101] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101, 824 June 2005. 826 [RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed 827 Authoring and Versioning (WebDAV)", RFC 4918, June 2007. 829 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 830 RFC 4949, August 2007. 832 [RFC5025] Rosenberg, J., "Presence Authorization Rules", RFC 5025, 833 December 2007. 835 [RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J., 836 Tschofenig, H., and H. Schulzrinne, "An Architecture for 837 Location and Location Privacy in Internet Applications", 838 BCP 160, RFC 6280, July 2011. 840 [Solove] Solove, D., "Understanding Privacy", 2010. 842 [Tor] The Tor Project, Inc., "Tor", 2011. 844 Authors' Addresses 846 Alissa Cooper 847 CDT 848 1634 Eye St. NW, Suite 1100 849 Washington, DC 20006 850 US 852 Phone: +1-202-637-9800 853 Email: acooper@cdt.org 854 URI: http://www.cdt.org/ 856 Hannes Tschofenig 857 Nokia Siemens Networks 858 Linnoitustie 6 859 Espoo 02600 860 Finland 862 Phone: +358 (50) 4871445 863 Email: Hannes.Tschofenig@gmx.net 864 URI: http://www.tschofenig.priv.at 866 Bernard Aboba 867 Microsoft Corporation 868 One Microsoft Way 869 Redmond, WA 98052 870 US 872 Email: bernarda@microsoft.com 874 Jon Peterson 875 NeuStar, Inc. 876 1800 Sutter St Suite 570 877 Concord, CA 94520 878 US 880 Email: jon.peterson@neustar.biz 882 John B. Morris, Jr. 884 Email: ietf@jmorris.org