idnits 2.17.00 (12 Aug 2021) /tmp/idnits46079/draft-cooper-ietf-privacy-requirements-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 20, 2013) is 3164 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: BCP S. Farrell 5 Expires: March 24, 2014 Trinity College Dublin 6 S. Turner 7 IECA, Inc. 8 September 20, 2013 10 Privacy Requirements for IETF Protocols 11 draft-cooper-ietf-privacy-requirements-00.txt 13 Abstract 15 It is the consensus of the IETF that IETF 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 March 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 5 57 4. Examples and Explanation . . . . . . . . . . . . . . . . . . . 6 58 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 59 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 60 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 61 8. Informative References . . . . . . . . . . . . . . . . . . . . 10 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 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 protocols. [RFC6973] explains the 76 many different aspects of privacy that can be affected by Internet 77 protocol design and provides guidance to help designers consider 78 privacy in their work. This document extends the existing body of 79 IETF principles concerning security by articulating Best Current 80 Practices for avoiding egregious privacy violations and establishing 81 support for privacy as a principle of IETF protocol design. 83 These principles, old and new, should be applied when designing new 84 protocols, and where applicable, should be considered for updates of 85 existing protocols. 87 Discussion of this draft is directed to the ietf-privacy@ietf.org 88 list. 90 2. Terminology 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 94 "OPTIONAL" in this document are to be interpreted as described in 95 [RFC2119]. These words take their normative meanings only when they 96 are presented in ALL UPPERCASE. 98 "Opportunistic encryption" is defined as encryption without any pre- 99 arrangement specific to the pair of systems involved (see [RFC4322]). 101 Privacy-specific terminology is provided in [RFC6973]. Of particular 102 relevance to this document is the term "personal data," defined as 103 "any information relating to an individual who can be identified, 104 directly or indirectly." Identifiers such as IP addresses that can 105 remain consistent over time or that particular parties associate with 106 directly identifiable information (such as a real name or street 107 address) are therefore considered to be personal data. 109 3. Recommendations 111 There are inherent privacy risks with protocols that allow the 112 communicating parties to store personal data, transport personal 113 data, or are vulnerable to other parties observing the personal data 114 in the exchanged communications. Most Internet communications 115 involve such risks, which can allow entities to build large databases 116 of information that by themselves or in conjunction with other 117 databases can identify people and their actions in invasive ways. 119 Therefore, to the extent consistent with basic protocol operation and 120 management, standards-track IETF protocols that involve transmission 121 of personal data: 123 1. MUST minimize their use of such personal data, and, 125 2. where personal data is sent, MUST have well-defined and 126 interoperable ways to send such data encrypted for the intended 127 recipient(s). 129 While existing principles call for strong security, it is important 130 to note that strong security only in cases where the other party can 131 be authenticated does not by itself solve all privacy problems. To 132 guard against dangers of large-scale privacy attacks, some protection 133 is needed also for other situations. As a consequence, at minimum, 134 opportunistic encryption needs to be well-defined for almost all new 135 IETF standards track protocols. In most cases it will be better to 136 (also) specify how to do mutually authenticated encryption. 137 Encryption provides one aspect of privacy protection, namely 138 confidentiality. 140 Note that this is contingent on practicality - if some personal data 141 really has to be sent in clear for a protocol to be able to operate, 142 and even opportunistic encryption is not possible, then a standards- 143 track protocol that does not define how to protect that data will be 144 consistent with this BCP. The IETF will have to decide in such cases 145 whether standardising that protocol benefits the Internet or not. 147 Many IETF protocols allow for some data items to be optionally or 148 conditionally sent. If personal data can be sent, then the 149 conditions above apply. 151 Specifications that do not meet the criteria above MUST include (or 152 reference) an explanation of why they do not conform to this BCP. 154 4. Examples and Explanation 156 This section has some examples and explanatory material. [[More, 157 including references, will be added as discussion evolves.]] 159 DHCP is an example of a protocol where it seems quite hard to provide 160 useful confidentiality. Should a new DHCP option be defined that 161 carries personal data, then the IETF would have to decide if the 162 benefit of that outweighs the potential privacy cost. 164 For some protocols, layering on top of a security protocol like TLS, 165 SSH or IPsec can be a useful way to provide confidentiality. 166 However, just because it could be possible to do that does not mean 167 that that is sufficient to claim conformance with this BCP. For 168 example, claiming that Diameter conformed to this BCP becuase one 169 could in principle run Diameter over IPsec would not be credible, as 170 it seems that such deployments are rare to non-existent. In the same 171 way that being being realistic is important when we consider a claim 172 that sending personal data is unavoidable, it is just as important 173 when claiming that layering on top of a security protocol can meet 174 the requirements of this BCP. 176 For some protocols, minimizing the use of personal data involves 177 limiting the lifetime of identifiers. In cases where an identifier 178 refers to an individual (or a proxy for an individual, such as a host 179 device or software instance), the longer that identifier persists and 180 the more contexts in which it is used, the more it can facilitate 181 correlation and tracking of information related to the individual and 182 his or her activities. Creating identifiers that have limited 183 lifetimes by default reduces the possibility that multiple protocol 184 interactions or communications can be correlated back to the same 185 individual. [RFC4941] provides an example in the case of stateless 186 autoconfiguration of IPv6 interface identifiers. 188 Since the goal here is to have a BCP that covers all IETF standards 189 track protocols we clearly cannot address all aspects of privacy, for 190 example user participation, since that would only be relevant for a 191 small proportion of IETF protocols. 193 One could consider mininimising the personal data sent by IETF 194 protocols as a form being conservative in what you send, one of the 195 longest standing principles in IETF protocol design. There doesn't 196 seem to be an equivalent here for being liberal in what you accept. 198 5. Security Considerations 200 This document articulates a set of Best Current Practices for privacy 201 that extend the IETF's existing security principles. [To do: Fill in 202 some text about potential tension between privacy and security, e.g., 203 with non-persistent identifiers, etc.] 205 6. IANA Considerations 207 This document does not require actions by IANA. 209 7. Acknowledgements 211 Thanks to the following for useful comments. These folks may or may 212 not agree with the content. 214 Jari Arkko, Bernard Aboba, Benoit Claise, Nick Doty, Spencer Dawkins, 215 Eliot Lear, Ted Lemon, 217 8. Informative References 219 [RFC1984] IAB, IESG, Carpenter, B., and F. Baker, "IAB and IESG 220 Statement on Cryptographic Technology and the Internet", 221 RFC 1984, August 1996. 223 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 224 Requirement Levels", BCP 14, RFC 2119, March 1997. 226 [RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, 227 May 2000. 229 [RFC3365] Schiller, J., "Strong Security Requirements for Internet 230 Engineering Task Force Standard Protocols", BCP 61, 231 RFC 3365, August 2002. 233 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 234 Text on Security Considerations", BCP 72, RFC 3552, 235 July 2003. 237 [RFC4322] Richardson, M. and D. Redelmeier, "Opportunistic 238 Encryption using the Internet Key Exchange (IKE)", 239 RFC 4322, December 2005. 241 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 242 Extensions for Stateless Address Autoconfiguration in 243 IPv6", RFC 4941, September 2007. 245 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 246 Morris, J., Hansen, M., and R. Smith, "Privacy 247 Considerations for Internet Protocols", RFC 6973, 248 July 2013. 250 Authors' Addresses 252 Alissa Cooper 253 CDT 254 1634 Eye St. NW, Suite 1100 255 Washington, DC 20006 256 US 258 Phone: +1-202-637-9800 259 Email: acooper@cdt.org 260 URI: http://www.cdt.org/ 262 Stephen Farrell 263 Trinity College Dublin 264 Dublin, 2 265 Ireland 267 Phone: +353-1-896-2354 268 Email: stephen.farrell@cs.tcd.ie 270 Sean Turner 271 IECA, Inc. 272 3057 Nutley Street, Suite 106 273 Fairfax, VA 22031 274 USA 276 Phone: +1.703.628.3180 277 Email: turners@ieca.com