idnits 2.17.1 draft-cooper-ietf-privacy-requirements-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 : ---------------------------------------------------------------------------- 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 (October 21, 2013) is 3832 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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: Best Current Practice S. Farrell 5 Expires: April 24, 2014 Trinity College Dublin 6 S. Turner 7 IECA, Inc. 8 October 21, 2013 10 Privacy Requirements for IETF Protocols 11 draft-cooper-ietf-privacy-requirements-01.txt 13 Abstract 15 It is the consensus of the IETF that our protocols be designed to 16 avoid privacy violations to the extent possible. This document 17 establishes a number of protocol design choices as Best Current 18 Practices for the purpose of avoiding such violations. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on April 24, 2014. 37 Copyright Notice 39 Copyright (c) 2013 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 56 3. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. Examples and Explanation . . . . . . . . . . . . . . . . . . 4 58 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 59 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 60 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 61 8. Informative References . . . . . . . . . . . . . . . . . . . 6 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 64 1. Introduction 66 The IETF has long-standing principles that support strong security in 67 protocol design and a tradition of encouraging protocol designers to 68 take these principles into account. [RFC1984] articulated the view 69 that encryption is an important tool to protect the cofidentiality of 70 communications, and that as such it should be encouraged and 71 available to all. [RFC3365] requires that all protocols implement 72 strong security. [RFC3552] provides guidance about how to consider 73 security in protocol design and how to document security choices. In 74 [RFC2804], the IETF established a policy of not considering 75 wiretapping requirements in IETF standards-track protocols. 76 [RFC6973] explains the many different aspects of privacy that can be 77 affected by Internet protocol design and provides guidance to help 78 designers consider privacy in their work. 80 This document extends the existing body of IETF principles concerning 81 security by articulating Best Current Practices for avoiding privacy 82 violations and establishing support for privacy as a principle of 83 IETF protocol design. These principles, old and new, should be 84 applied when designing new protocols, and where applicable, should be 85 considered for updates of existing protocols. 87 It is also the consensus of the IETF that pervasive surveillance is 88 an attack on privacy that should be defended against through protocol 89 design. 91 Discussion of this draft is directed to the ietf-privacy@ietf.org 92 list. 94 2. Terminology 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 97 "OPTIONAL" in this document are to be interpreted as described in 98 [RFC2119]. These words take their normative meanings only when they 99 are presented in ALL UPPERCASE. 101 "Opportunistic encryption" is defined as encryption without any pre- 102 arrangement specific to the pair of systems involved (e.g., by using 103 a Diffie-Hellman exchange). See [RFC4322]. 105 Privacy-specific terminology is provided in [RFC6973]. Of particular 106 relevance to this document is the term "personal data," defined as 107 "any information relating to an individual who can be identified, 108 directly or indirectly." Identifiers such as IP addresses that can 109 remain consistent over time or that particular parties associate with 110 directly identifiable information (such as a real name or street 111 address) are therefore considered to be personal data. 113 3. Recommendations 115 There are inherent privacy risks with protocols that allow the 116 communicating parties to store personal data, transport personal 117 data, or are vulnerable to other parties observing the personal data 118 in the exchanged communications. Most Internet communications 119 involve such risks, which can allow entities to build large databases 120 of information that by themselves or in conjunction with other 121 databases can identify people and their actions in invasive ways. 123 Therefore, to the extent consistent with basic protocol operation and 124 management, standards-track IETF protocols that involve transmission 125 of personal data: 127 1. MUST minimize their use of such personal data, and 129 2. where personal data is sent, MUST have well-defined and 130 interoperable ways to send such data encrypted for the intended 131 recipient(s). 133 While existing principles call for strong security, it is important 134 to note that strong security only in cases where the other party can 135 be authenticated does not by itself solve all privacy problems. To 136 guard against dangers of large-scale privacy attacks, some protection 137 is needed also for other situations. 139 As a consequence, at minimum, opportunistic encryption MUST be well- 140 defined for new IETF standards track protocols. This requirement can 141 be waived only in exceptional circumstances where the protocol's 142 utility would be eliminated or severely diminished if opportunistic 143 encryption were defined. Note that encryption provides one aspect of 144 privacy protection, namely confidentiality. In most cases it will be 145 better to (also) specify how to do one-sided (e.g., TLS server 146 authentication as commonly used in the web) or mutually authenticated 147 encryption. Where both opportunistic and one-sided or mutually 148 authenticated encryption are specified, protocols MUST also protect 149 against downgrade attacks so that scenarios where authentication is 150 required cannot easily be manipulated into using opportunistic 151 encryption which will often be subject to man-in-the-middle attacks. 153 Note that these encryption requirements are contingent on 154 practicality - if some personal data really has to be sent in clear 155 for a protocol to be able to operate, and even opportunistic 156 encryption is not possible, then a standards-track protocol that does 157 not define how to protect that data will be consistent with this BCP. 158 The IETF will have to decide in such cases whether standardising that 159 protocol benefits the Internet or not. 161 Many IETF protocols allow for some data items to be optionally or 162 conditionally sent. If personal data can be sent, then the 163 conditions above apply. 165 Specifications that do not meet the criteria above MUST include (or 166 reference) an explanation of why they do not conform to this BCP. 168 4. Examples and Explanation 170 This section has some examples and explanatory material. [[More, 171 including references, will be added as discussion evolves.]] 173 DHCP is an example of a protocol where it seems quite hard to provide 174 useful confidentiality. Should a new DHCP option be defined that 175 carries personal data, then the IETF would have to decide if the 176 benefit of that outweighs the potential privacy cost. 178 For some protocols, layering on top of a security protocol like TLS, 179 SSH or IPsec can be a useful way to provide confidentiality. 180 However, just because it could be possible to do that does not mean 181 that that is sufficient to claim conformance with this BCP. For 182 example, claiming that Diameter conformed to this BCP becuase one 183 could in principle run Diameter over IPsec would not be credible, as 184 it seems that such deployments are rare to non-existent. In the same 185 way that being being realistic is important when we consider a claim 186 that sending personal data is unavoidable, it is just as important 187 when claiming that layering on top of a security protocol can meet 188 the requirements of this BCP. 190 For some protocols, minimizing the use of personal data involves 191 limiting the lifetime of identifiers. In cases where an identifier 192 refers to an individual (or a proxy for an individual, such as a host 193 device or software instance), the longer that identifier persists and 194 the more contexts in which it is used, the more it can facilitate 195 correlation and tracking of information related to the individual and 196 his or her activities. Creating identifiers that have limited 197 lifetimes by default reduces the possibility that multiple protocol 198 interactions or communications can be correlated back to the same 199 individual. [RFC4941] provides an example in the case of stateless 200 autoconfiguration of IPv6 interface identifiers. 202 Since the goal here is to have a BCP that covers all IETF standards 203 track protocols we clearly cannot address all aspects of privacy, for 204 example user participation, since that would only be relevant for a 205 small proportion of IETF protocols. 207 One could consider mininimising the personal data sent by IETF 208 protocols as a form being conservative in what you send, one of the 209 longest standing principles in IETF protocol design. There doesn't 210 seem to be an equivalent here for being liberal in what you accept. 212 5. Security Considerations 214 This document articulates a set of Best Current Practices for privacy 215 that extend the IETF's existing security principles. At times, 216 privacy and security may appear to be in tension. For example, 217 adherence to the recommendation in this BCP to minimize the use of 218 personal data will likely yield less use of persistent identifiers 219 associated with individual users. Reducing the use of persistent 220 identifiers can help attackers shield their identities and activities 221 just as it can for legitimate users. However, even relatively 222 unsophisticated attackers already have at their disposal a variety of 223 tools for cloaking their identities. Recommending the minimization 224 of personal data use at the protocol level can benefit the vast 225 majority of legitimate users who depend on IETF protocols without 226 materially improving attackers' existing tools for guarding their 227 identities. 229 Similarly, malware and other attack traffic can generally already be 230 transmitted using object encryption or protocol encryption if 231 attackers so choose. Recommending that IETF protocols define 232 mechanisms for opportunistic encryption can increase the availability 233 of confidentiality protection to legitimate users without 234 significantly changing the set of tools that attackers already use to 235 shield their traffic from being identified and their attacks from 236 being thwarted. 238 6. IANA Considerations 240 This document does not require actions by IANA. 242 7. Acknowledgements 244 Thanks to the following for useful comments. These folks may or may 245 not agree with the content. 247 Jari Arkko, Bernard Aboba, Scott Brim, Benoit Claise, Nick Doty, 248 Spencer Dawkins, Eliot Lear, Ted Lemon, SM, Avri Doria, Brian 249 Trammell, Robin Wilton, 251 8. Informative References 253 [RFC1984] IAB, IESG, Carpenter, B., and F. Baker, "IAB and IESG 254 Statement on Cryptographic Technology and the Internet", 255 RFC 1984, August 1996. 257 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 258 Requirement Levels", BCP 14, RFC 2119, March 1997. 260 [RFC2804] IAB IESG, "IETF Policy on Wiretapping", RFC 2804, May 261 2000. 263 [RFC3365] Schiller, J., "Strong Security Requirements for Internet 264 Engineering Task Force Standard Protocols", BCP 61, RFC 265 3365, August 2002. 267 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 268 Text on Security Considerations", BCP 72, RFC 3552, July 269 2003. 271 [RFC4322] Richardson, M. and D. Redelmeier, "Opportunistic 272 Encryption using the Internet Key Exchange (IKE)", RFC 273 4322, December 2005. 275 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 276 Extensions for Stateless Address Autoconfiguration in 277 IPv6", RFC 4941, September 2007. 279 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 280 Morris, J., Hansen, M., and R. Smith, "Privacy 281 Considerations for Internet Protocols", RFC 6973, July 282 2013. 284 Authors' Addresses 285 Alissa Cooper 286 CDT 287 1634 Eye St. NW, Suite 1100 288 Washington, DC 20006 289 US 291 Phone: +1-202-637-9800 292 Email: acooper@cdt.org 293 URI: http://www.cdt.org/ 295 Stephen Farrell 296 Trinity College Dublin 297 Dublin 2 298 Ireland 300 Phone: +353-1-896-2354 301 Email: stephen.farrell@cs.tcd.ie 303 Sean Turner 304 IECA, Inc. 305 3057 Nutley Street, Suite 106 306 Fairfax, VA 22031 307 USA 309 Phone: +1.703.628.3180 310 Email: turners@ieca.com