idnits 2.17.1 draft-andersdotter-intarea-update-to-rfc6302-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 document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (April 22, 2018) is 2195 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IntArea Working Group A. Andersdotter 3 Internet-Draft ARTICLE 19 4 Intended status: Informational April 22, 2018 5 Expires: October 24, 2018 7 An update to RFC6302 on Logging Recommendations for Internet-Facing 8 Servers 9 draft-andersdotter-intarea-update-to-rfc6302-00 11 Abstract 13 This draft seeks to update RFC6302 on Logging Recommendations for 14 Internet-Facing Servers. The new recommendations aim to be a best 15 practice for service providers and server maintainers, by following 16 recommendations outlined in RFC6973 and taking into account new 17 regulatory requirements in the privacy area. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on October 24, 2018. 36 Copyright Notice 38 Copyright (c) 2018 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Recommendations for Internet-facing servers . . . . . . . . . 3 56 3.1. Data minimization . . . . . . . . . . . . . . . . . . . . 4 57 3.2. User involvement . . . . . . . . . . . . . . . . . . . . 4 58 3.3. Security . . . . . . . . . . . . . . . . . . . . . . . . 5 59 4. Considerations for electronic communications providers . . . 5 60 5. Security considerations . . . . . . . . . . . . . . . . . . . 5 61 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 62 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 64 7.2. Informative References . . . . . . . . . . . . . . . . . 6 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 67 1. Introduction 69 In 2013, the IETF adopted [RFC6973] Privacy Guidelines for Internet 70 protocols to ensure robust procedures for evaluating existing 71 protocols and standards with respect to privacy, and insert 72 protective mechanisms for privacy in future protocol and standards 73 work. In the past couple of years, new data privacy regulations with 74 wide geographical scope are entering into effect with big effects for 75 technology companies and technology consumers around the world. The 76 combination of these changes, in IETF procedure and regulatory 77 requirements, have caused some previously established best practices 78 to become poor practices. 80 This draft proposes updates to specifically [RFC6302] on Logging 81 Recommendations for Internet-Facing Servers with a view for it to 82 serve as a useful reference for operators seeking to be compliant 83 with modern regulatory requirements for the protection of end-users, 84 e.g. [GDPR]. 86 Earlier recommendations contained in [RFC6302] relied heavily on 87 observations made in Section 12 of [RFC6269] that regulatory 88 requirements could imply a broad obligation to log identifiers. At 89 the time of the adoption of [RFC6302], it was known that European 90 Union law mandated data retention and trace-ability of each and every 91 telecommunications subscriber in the European Union. The regulatory 92 landscape in Europe has since changed, for instance in the European 93 Union through [C20315], and in the broader Council of Europe area 94 through [Zakharov] and [SzaboVissy]. It is possible that [RFC6269] 95 should be revisited in light of these developments, but such work is 96 outside the scope of this text. 98 The below text is intended to replace Section 1 in [RFC6302]. 100 Service providers, in so far as they are a collection of individual 101 persons, and subscribers, and the transactional relationships of 102 these individuals with the service provision, all give rise to 103 personal data. In [RFC6973] it is specified that data minimization 104 and security are important mitigation strategies against privacy 105 threats. Further, regulatory requirements place an obligation on 106 protocol designers and operators of servers to implement privacy-by- 107 design and data minimization techniques. 109 [RFC6973] as well as new regulatory requirements have been put in 110 place to protect the privacy of internet users. They are in the vein 111 of previous IETF work on pervasive monitoring as a security risk in 112 and of itself [RFC7258], and have parallels in new developments in 113 international human rights law, see e.g. [UNGA2013]. 115 2. Terminology 117 This section is intended to be introduced in [RFC6302] as a separate 118 terminology section, replacing the first paragraph of Section 2 of 119 [RFC6302]. 121 The key words *MUST*, *MUST NOT*, *REQUIRED*, *SHALL*, *SHALL NOT*, 122 *SHOULD*, *SHOULD NOT*, *RECOMMENDED*, *MAY* and *OPTIONAL* in this 123 document as to be interpreted as described in [RFC2119]. 125 This document adheres to the privacy terminology established in 126 [RFC6973]. 128 3. Recommendations for Internet-facing servers 130 This section is intended to replace Section 2 of [RFC6302]. 132 Providers of internet-facing servers 134 SHOULD only store entire incoming IP addresses for as long as is 135 necessary to provide the specific service requested by the user. 137 SHOULD keep only the first two octets (of an IPv4 address) or the 138 first three octets (of an IPv6 address) with remaining octets set 139 to zero, when logging. 141 SHOULD NOT store logs of incoming IP addresses from inbound 142 traffic for longer than three days. 144 SHOULD NOT log unnecessary identifiers, such as source port 145 number, time stamps, transport protocol numbers or destination 146 port numbers. 148 SHOULD ensure adequate log access control, with suitable 149 mechanisms for keeping track of which entity accesses logged 150 identifiers, for what reason and at what time. 152 It is RECOMMENDED that deviations from the above practices are 153 carefully documented and communicated to subscribers. 155 3.1. Data minimization 157 Data minimization is proposed by Section 6.1 in [RFC6973] as an 158 effective way of ensuring privacy protections. A data minimization 159 principle is further a regulatory requirement in some parts of the 160 world (e.g. [GDPR]). 162 Data minimization can be effectuated in a number of different ways, 163 including by limiting collection, retention and identifiability to 164 personal data. The recommendation to anonymize IP addresses intended 165 for logging, the recommendation not to store logs for longer than a 166 limited amount of time, and the recommendation not to log unnecessary 167 identifiers are intended to advance such effectuations of data 168 minimization. 170 A three-day logging period covers a week-end, which is convenient for 171 professional server providers. It also accounts for the ability of 172 content providers to geolocate subscribers for the duration of their 173 content consumption, in those cases where this is necessary due to 174 legal restrictions. 176 3.2. User involvement 178 In Section 6.2 of [RFC6973] it is established involving individuals 179 in decisions about data collection and treatment of data is a way of 180 mitigating privacy threats. The section proposes that individuals be 181 informed, and that they are provided ways to signal their 182 preferences, and make choices, about collection and sharing of data. 184 Identifiers about subscribers can be logged at an internet-facing 185 server to enable provision of content that is geoblocked, but are 186 only required for as long as the service is requested by the user. 187 In these circumstances, data which is logged for longer than the time 188 it takes to deliver the service should be subject to careful 189 considerations and the subscriber should be informed thereof. 191 Similarly, there exists no duty of subscribers to assist internet- 192 facing servers in their efforts to improve services or the Internet. 193 Where IP addresses or identifiers about individuals are logged with a 194 view to improving services or the Internet, and having no other 195 technical justification, individuals should be given a way to signal 196 preferences and make choices about such logging. 198 3.3. Security 200 Security is advanced by Section 6.3 of [RFC6973] as an effective way 201 to mitigate privacy threats. Among the important security goals 202 mentioned are confidentiality, unauthorized usage and inappropriate 203 usage. The recommendation to have adequate access control is 204 intended to ensure security in the handling of such logs that are 205 kept even after the data minimization strategies are deployed. 207 4. Considerations for electronic communications providers 209 This section is intended to replace Section 3 of [RFC6302]. 211 The new regulatory requirements referenced earlier in this document 212 imply that electronic communications providers may also have to 213 review their logging practices. It is advisable that they should do 214 so, bearing in mind [RFC6973]. However, the details are outside the 215 scope of this document. 217 5. Security considerations 219 This draft gives recommendations for logging at internet-facing 220 servers. It is intended to protect internet users from the threats 221 of pervasive monitoring [RFC7258] and to assist operators of 222 internet-facing servers in adhering to regulatory requirements. 224 Operators seeking to deviate from the base-level of privacy and 225 security assumed for internet users, should make time-limited, 226 specific exceptions which have clearly stated and lawful aims. 227 Deviations could for instance be included in employment contracts or 228 consumer contracts that are tied to non-public services which are 229 nevertheless provided through Internet-facing servers and which 230 require authentication for access. 232 6. Acknowledgments 234 The author would like to thank Mallory Knodel, Linus Nordberg and 235 Anders Jensen-Urstad for their comments during the drafting of this 236 document. 238 7. References 240 7.1. Normative References 242 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 243 Requirement Levels", RFC 2119, DOI 10.17487/RFC2119, March 244 1997, . 246 7.2. Informative References 248 [C20315] Court of Justice of the European Union, 249 "ECLI:EU:C:2016:970, Judgment of the Court (Grand Chamber) 250 of 21 December 2016, Tele2 Sverige AB v Post- och 251 telestyrelsen and Secretary of State for the Home 252 Department v Tom Watson and Others", December 2016, 253 . 255 [GDPR] European Union, "Regulation (EU) 2016/679 (General Data 256 Protection Regulation)", May 2016, 257 . 259 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 260 Roberts, "Issues with IP Address Sharing", RFC 6269, 261 DOI 10.17487/RFC6269, June 2011, 262 . 264 [RFC6302] Durand, A., Gashinsky, I., Lee, D., and S. Sheppard, 265 "Logging Recommendations for Internet-Facing Servers", 266 RFC 6302, DOI 10.17487/RFC6302, June 2011, 267 . 269 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Petersen, J., 270 Morris, J., Hansen, M., and R. Smith, "Privacy 271 Considerations for Internet Protocols", RFC 6973, 272 DOI 10.17487/RFC6973, July 2013, 273 . 275 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 276 Attack", RFC 7258, DOI 10.17487/RFC7258, May 2017, 277 . 279 [SzaboVissy] 280 European Court of Human Rights, "Case of Szabo and Vissy 281 v. Hungary, Application no. 37138/14, ECHR 2016", January 282 2016, . 284 [UNGA2013] 285 United Nations General Assembly, ""The right to privacy in 286 the digital age" (A/C.3/68/L.45)", 2013, 287 . 289 [Zakharov] 290 European Court of Human Rights, "Case of Zakharov v. 291 Russia, Application no. 47143/06, ECHR 2015.", December 292 2015, . 294 Author's Address 296 Amelia Andersdotter 297 ARTICLE 19 298 Free Word Centre, 60 Farringdon Road 299 London EC1R 3GA 300 United Kingdom 302 Email: amelia@article19.org