idnits 2.17.1 draft-sahib-451-new-protocol-elements-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([2], [1]), 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 (June 29, 2018) is 2128 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 391 -- Looks like a reference, but probably isn't: '2' on line 393 Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Sahib 3 Internet-Draft June 29, 2018 4 Intended status: Informational 5 Expires: December 31, 2018 7 New protocol elements for HTTP Status Code 451 8 draft-sahib-451-new-protocol-elements-01 10 Abstract 12 This draft recommends protocol updates to Hypertext Transfer Protocol 13 (HTTP) status code 451 (defined by RFC7725) based on an examination 14 of how the new status code is being used by parties involved in 15 denial of Internet resources because of legal demands. Also included 16 is an analysis of HTTP 451 from a human rights perspective using 17 guidelines from RFC8280. 19 Discussion of this draft is at https://www.irtf.org/mailman/listinfo/ 20 hrpc [1] and https://lists.ghserv.net/mailman/listinfo/statuscode451 21 [2]. 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 December 31, 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. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Existing Protocol Elements . . . . . . . . . . . . . . . . . 3 60 4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 3 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 63 7. Human Rights Considerations . . . . . . . . . . . . . . . . . 5 64 7.1. Connectivity . . . . . . . . . . . . . . . . . . . . . . 5 65 7.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 7.3. Content Agnosticism . . . . . . . . . . . . . . . . . . . 5 67 7.4. Security . . . . . . . . . . . . . . . . . . . . . . . . 5 68 7.5. Internationalization . . . . . . . . . . . . . . . . . . 5 69 7.6. Censorship Resistance . . . . . . . . . . . . . . . . . . 6 70 7.7. Open Standards . . . . . . . . . . . . . . . . . . . . . 6 71 7.8. Heterogeneity Support . . . . . . . . . . . . . . . . . . 6 72 7.9. Anonymity . . . . . . . . . . . . . . . . . . . . . . . . 6 73 7.10. Pseudonymity . . . . . . . . . . . . . . . . . . . . . . 6 74 7.11. Accessibility . . . . . . . . . . . . . . . . . . . . . . 6 75 7.12. Localization . . . . . . . . . . . . . . . . . . . . . . 6 76 7.13. Decentralization . . . . . . . . . . . . . . . . . . . . 6 77 7.14. Reliability . . . . . . . . . . . . . . . . . . . . . . . 7 78 7.15. Confidentiality . . . . . . . . . . . . . . . . . . . . . 7 79 7.16. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 7 80 7.17. Authenticity . . . . . . . . . . . . . . . . . . . . . . 7 81 7.18. Adaptability . . . . . . . . . . . . . . . . . . . . . . 7 82 7.19. Outcome Transparency . . . . . . . . . . . . . . . . . . 7 83 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8 84 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 85 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 86 9.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 9 87 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 89 1. Introduction 91 [RFC7725] was standardized by the IETF in February 2016. It defined 92 HTTP status code 451 - to be used when a "a server operator has 93 received a legal demand to deny access to a resource or to a set of 94 resources". 96 Subsequently, an effort was made to investigate usage of HTTP 451 and 97 evaluate if it fulfills its mandate of providing "transparency in 98 circumstances where issues of law or public policy affect server 99 operations" [IMPL_REPORT_DRAFT]. This draft attempts to explicate 100 the protocol recommendations arising out of that investigation. In 101 addition, specific recommendations are made in order to disambiguate 102 cases where the status code may or may not be used. 104 2. Requirements 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [RFC2119]. 110 3. Existing Protocol Elements 112 The status code as standardized by the IETF specifies the following 113 elements [RFC7725] - 115 - A server can return status code 451 to indicate that it is denying 116 access to a resource or multiple resources on account of a legal 117 demand. Note that while the introduction of [RFC7725] mentions 118 that the legal demand for denial of access should be related to 119 the resource being requested, the RFC's description does not make 120 it clear that the resource being denied access to must be directly 121 mentioned in the legal demand. 123 - Responses using the status code SHOULD include an explanation in 124 the response body of the details of the legal demand. 126 - Responses SHOULD include a "Link" HTTP header field [RFC8288] 127 whose value is a URI reference [RFC3986] identifying itself. The 128 "Link" header field MUST have a "rel" parameter whose value is 129 "blocked-by". The intent is that the header be used to identify 130 the entity actually implementing blockage, not any other entity 131 mandating it. 133 4. Recommendations 135 - HTTP 451 SHOULD NOT be used by an operator to deny access to a 136 resource on the basis of a legal demand that is not specific to 137 the requested resource. 139 - HTTP 451 SHOULD NOT be used by an operator to deny access to a 140 resource on the basis of a policy specified by the operator (as 141 opposed to a legal demand being placed on the operator). 143 - In addition to the "blocked-by" header, an HTTP response with 144 status code 451 SHOULD include another "Link" HTTP header field 145 which has a "rel" parameter whose value is "blocking-authority". 146 It's important to distinguish between the implementer of the 147 block, and the authority that mandated the block in the first 148 place. This is because these two organizations might not be the 149 same - a government (the blocking authority) could force an 150 Internet Service Provider (the implementer of the block) to deny 151 access to a certain resource. [IMPL_REPORT_DRAFT] notes that 152 there is confusion amongst implementors of [RFC7725] about the 153 meaning of the term "blocked-by", perhaps in part because of the 154 example given [ERRATA_ID-5181] - it would be useful to explicitly 155 include space for both, as both provide essential information 156 about the legal block. 158 - HTTP status code 451 is increasingly being used to deny access to 159 resources based on geographical IP. The response SHOULD contain a 160 provisional header with geographical scope of block. This scope 161 SHOULD correspond to comma-separated list of alpha-2 country codes 162 defined in [ISO.3166-1]. The rationale for keeping the 163 geographical scope to country-level granularity is that most 164 blocks are mandated by national governments [IMPL_REPORT_DRAFT]. 165 In addition, as the serving of this status code is voluntary, 166 there is value in not complicating the specification. 168 5. Security Considerations 170 This document does not add additional security considerations to 171 [RFC7725]. 173 6. IANA Considerations 175 The Link Relation Type Registry should be updated with the following 176 entry: 178 - Relation Name: blocking-authority 180 - Description: Identifies the authority that has issued the block. 182 - Reference: this document 184 In addition, IANA should be updated with the following provisional 185 header: 187 - Header field name: geo-scope-block 189 - Applicable protocol: http 190 - Status: provisional 192 - Specification document(s): this document 194 7. Human Rights Considerations 196 The use of HTTP 451 has implications for human rights, and is thus 197 worth examining under the guidelines for developing human rights 198 considerations for protocols [RFC8280]. 200 7.1. Connectivity 202 HTTP 451 status code response can be sent by the server hosting the 203 blocked resource (end node) or an intermediary node that implements 204 the block. If a resource is "blocked-by" a particular ISP then the 205 ISP will be the one serving the status code. 207 7.2. Privacy 209 HTTP 451 is used as a response when the client requests a resource 210 that's unavailable because of legal reasons. Consequentially, there 211 are potential privacy (and anonymity) ramifications if there is 212 leakage of who accessed what resource. 214 HTTP status code 451 is cacheable by default [RFC7725]. Caching 215 status code 451 on users' devices means that there will be a record 216 of their attempt to access the blocked content stored on their 217 devices. If caching is used, the software used to access the web 218 resource should notify users that the HTTP 451 response has been 219 received and cached. 221 7.3. Content Agnosticism 223 The scope of the blocking order may be geographical in nature. This 224 results in an issue related to content agnosticism. This is not a 225 protocol issue, but rather an artefact of the blocking order. 227 7.4. Security 229 Refer to section 5, Security Considerations, of [RFC7725]. 231 7.5. Internationalization 233 [RFC7725] does not require the use of any particular language for 234 user-facing strings such as the response body or the value of the 235 header fields. The header field names, however, are in English. 236 This is a common attribute of protocol elements within the IETF 237 [RFC2277]. 239 7.6. Censorship Resistance 241 While HTTP 451 status code cannot prevent censorship, it can help 242 make some kinds of censorship (i.e. where the censorer is interested 243 and able to provide information about the block) more transparent and 244 make its assessment easier by providing information about the block 245 in a parseable manner. 247 7.7. Open Standards 249 [RFC7725] is an open standard. 251 7.8. Heterogeneity Support 253 An HTTP 451 status code response can be used for any web resource and 254 for any software that is capable of understanding HTTP header 255 responses. 257 7.9. Anonymity 259 HTTP 451 is an HTTP status code. If the connection between the 260 client and the server is not over HTTPS, then there is potential for 261 a network observer to identify what a particular user is accessing. 262 Even with HTTPS, meta-data might be available that could be used to 263 identify a user. 265 7.10. Pseudonymity 267 HTTP 451 does not involve pseudonyms or nicknames. 269 7.11. Accessibility 271 HTTP 451, being an HTTP status code, does not prescribe how the 272 client should parse the information contained in the response fields. 273 Depending on the software that is used to access the resource, there 274 could be accessibility concerns related to understanding this 275 information. 277 7.12. Localization 279 The values of the header fields and the response body can be 280 localized by the blocker to suit the geographical scope of the block. 282 7.13. Decentralization 284 HTTP 451 is used to provide information about a block mandated by a 285 (centralized) blocking authority. The status code itself does not 286 add any additional centralization. 288 7.14. Reliability 290 HTTP 451 does not by itself prevent the misuse of the status code or 291 wrong tagging of resources. The informational requirement as part of 292 the protocol address this concern to some extent, but commonly it 293 will be difficult for the end user to verify if the code has been 294 correctly used. Objective of this draft is to increase reliability 295 by making it clearer what a good HTTP 451 response looks like. 297 7.15. Confidentiality 299 HTTP 451 status code use implies sharing of information by the 300 reporter that make it easier to identify where censorship is taking 301 place. See section on Privacy and Anonymity. 303 7.16. Integrity 305 HTTP 451 does not prescribe the use of any encryption to transport 306 it, and is thus susceptible to leakage through man-in-the-middle 307 attacks. 309 7.17. Authenticity 311 Authenticity of the server implementing HTTP 451 is dependent on the 312 connection being over HTTPS. 314 7.18. Adaptability 316 HTTP 451 does not have any legal or technical limitations which 317 prevents the development of other standards / protocols. 319 7.19. Outcome Transparency 321 The assumption behind the development of the status code 451 is that 322 transparency has a chilling effect on censorship and that 323 transparency will allow acts of censorship to be challenged. In some 324 countries, blocks orders are unevenly implemented by ISPs either 325 because it does not serve their bottom-lines or they are resisting 326 censorship - governments in those countries could mandate the 327 implementation of status code 451 which will make it easier for them 328 to monitor the implementation of their block orders. Surveillance 329 systems in some countries could be updated to watch out for the 451 330 error code on unencrypted traffic making it easier to identify those 331 trying to access prohibited content. Before the implementation of 332 this standard there would be no uniformity in which websites would 333 implement a block order increasing the number of false positives for 334 any automated monitoring systems. 336 Acknowledgements 338 Thanks to Alp Toker, Christine Runnegar, Niels ten Oever, Stephane 339 Bortzmeyer, Corinne Cath and many others on the HRPC mailing list 340 (linked above) for reviewing and brainstorming. 342 9. References 344 9.1. Normative References 346 [ERRATA_ID-5181] 347 Bortzmeyer, S., "[Technical Errata Reported] RFC7725 348 (5181)", 2017, 349 . 351 [IMPL_REPORT_DRAFT] 352 Abraham, S., Canales, MP., Hall, J., Khrustaleva, O., ten 353 Oever, N., Runnegar, C., and S. Sahib, "Implementation 354 Report for HTTP Status Code 451", 2017, 355 . 357 [ISO.3166-1] 358 International Organization for Standardization, "Codes for 359 the representation of names of countries and their 360 subdivisions - Part 1: Country code", ISO Standard 3166- 361 1:1997 , 1997. 363 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 364 Requirement Levels", BCP 14, RFC 2119, 365 DOI 10.17487/RFC2119, March 1997, 366 . 368 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 369 Languages", BCP 18, RFC 2277, DOI 10.17487/RFC2277, 370 January 1998, . 372 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 373 Resource Identifier (URI): Generic Syntax", STD 66, 374 RFC 3986, DOI 10.17487/RFC3986, January 2005, 375 . 377 [RFC7725] Bray, T., "An HTTP Status Code to Report Legal Obstacles", 378 RFC 7725, DOI 10.17487/RFC7725, February 2016, 379 . 381 [RFC8280] ten Oever, N. and C. Cath, "Research into Human Rights 382 Protocol Considerations", RFC 8280, DOI 10.17487/RFC8280, 383 October 2017, . 385 [RFC8288] Nottingham, M., "Web Linking", RFC 8288, 386 DOI 10.17487/RFC8288, October 2017, 387 . 389 9.2. URIs 391 [1] https://www.irtf.org/mailman/listinfo/hrpc 393 [2] https://lists.ghserv.net/mailman/listinfo/statuscode451 395 Author's Address 397 Shivan Kaul Sahib 399 EMail: shivankaulsahib@gmail.com