idnits 2.17.1 draft-irtf-hrpc-guidelines-03.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 ([RFC6973], [RFC8280]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document updates RFC8280, but the abstract doesn't seem to directly say this. It does mention RFC8280 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 07, 2019) is 1778 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 1289 -- Looks like a reference, but probably isn't: '2' on line 1291 -- Looks like a reference, but probably isn't: '3' on line 1293 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Human Rights Protocol Considerations Research GroupN. ten Oever (editor) 3 Internet-Draft University of Amsterdam 4 Updates: 8280 (if approved) G. Grover (editor) 5 Intended status: Informational Centre for Internet and Society 6 Expires: December 9, 2019 June 07, 2019 8 Guidelines for Human Rights Protocol and Architecture Considerations 9 draft-irtf-hrpc-guidelines-03 11 Abstract 13 This document sets guidelines for human rights considerations in 14 networking protocols, similar to the work done on the guidelines for 15 privacy considerations [RFC6973]. This is an updated version of the 16 guidelines for human rights considerations in [RFC8280]. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on December 9, 2019. 35 Copyright Notice 37 Copyright (c) 2019 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Vocabulary used . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Guidelines for developing human rights protocol 55 considerations . . . . . . . . . . . . . . . . . . . . . . . 3 56 3.1. Human rights threats . . . . . . . . . . . . . . . . . . 3 57 3.2. Conducting human rights reviews . . . . . . . . . . . . . 5 58 3.2.1. Analyzing drafts based on guidelines for human rights 59 considerations model . . . . . . . . . . . . . . . . 5 60 3.2.2. Analyzing drafts based on their perceived or 61 speculated impact . . . . . . . . . . . . . . . . . . 5 62 3.2.3. Expert interviews . . . . . . . . . . . . . . . . . . 5 63 3.2.4. Interviews with impacted persons and communities . . 6 64 3.2.5. Tracing impacts of implementations . . . . . . . . . 6 65 3.3. Guidelines for human rights considerations . . . . . . . 6 66 3.3.1. Connectivity . . . . . . . . . . . . . . . . . . . . 7 67 3.3.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . 7 68 3.3.3. Content agnosticism . . . . . . . . . . . . . . . . . 8 69 3.3.4. Security . . . . . . . . . . . . . . . . . . . . . . 8 70 3.3.5. Internationalization . . . . . . . . . . . . . . . . 9 71 3.3.6. Censorship resistance . . . . . . . . . . . . . . . . 10 72 3.3.7. Open Standards . . . . . . . . . . . . . . . . . . . 11 73 3.3.8. Heterogeneity Support . . . . . . . . . . . . . . . . 12 74 3.3.9. Pseudonymity . . . . . . . . . . . . . . . . . . . . 13 75 3.3.10. Accessibility . . . . . . . . . . . . . . . . . . . . 14 76 3.3.11. Localization . . . . . . . . . . . . . . . . . . . . 15 77 3.3.12. Decentralization . . . . . . . . . . . . . . . . . . 15 78 3.3.13. Reliability . . . . . . . . . . . . . . . . . . . . . 16 79 3.3.14. Confidentiality . . . . . . . . . . . . . . . . . . . 17 80 3.3.15. Integrity . . . . . . . . . . . . . . . . . . . . . . 18 81 3.3.16. Authenticity . . . . . . . . . . . . . . . . . . . . 19 82 3.3.17. Adaptability . . . . . . . . . . . . . . . . . . . . 20 83 3.3.18. Outcome Transparency . . . . . . . . . . . . . . . . 20 84 3.3.19. Anonymity . . . . . . . . . . . . . . . . . . . . . . 21 85 4. Document Status . . . . . . . . . . . . . . . . . . . . . . . 22 86 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 87 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 88 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 89 8. Research Group Information . . . . . . . . . . . . . . . . . 23 90 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 91 9.1. Informative References . . . . . . . . . . . . . . . . . 23 92 9.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 28 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 95 1. Introduction 97 This document outlines a set of human rights protocol considerations 98 for protocol developers. It provides questions engineers should ask 99 themselves when developing or improving protocols if they want to 100 understand their potential human rights impact. It should however be 101 noted that the impact of a protocol cannot solely be deduced from its 102 design, but its usage and implementation should also be studied to 103 form a full protocol human rights impact assessment. 105 The questions are based on the research performed by the hrpc 106 research group which has been documented before these considerations. 107 The research establishes that human rights relate to standards and 108 protocols, and offers a common vocabulary of technical concepts that 109 impact human rights and how these technical concepts can be combined 110 to ensure that the Internet remains an enabling environment for human 111 rights. With this, the contours of a model for developing human 112 rights protocol considerations has taken shape. 114 This document is a further iteration of the guidelines that can be 115 found in [RFC8280]. The methods for conducting human rights reviews 116 (Section 3.2), and guidelines for human rights considerations 117 (Section 3.3) in this document are being tested for relevance, 118 accuracy and validity. 120 2. Vocabulary used 122 3. Guidelines for developing human rights protocol considerations 124 3.1. Human rights threats 126 Human rights threats on the Internet come in a myriad of forms. 127 Protocols and standards can harm or enable the right to freedom of 128 expression, right to non-discrimination, right to equal protection, 129 right to participate in cultural life, arts and science, right to 130 freedom of assembly and association, and the right to security. An 131 end-user who is denied access to certain services, data or websites 132 may be unable to disclose vital information about the malpractices of 133 a government or other authority. A person whose communications are 134 monitored may be prevented from exercising their right to freedom of 135 association or participate in political processes [Penney]. In a 136 worst-case scenario, protocols that leak information can lead to 137 physical danger. A realistic example to consider is when individuals 138 perceived as threats to the state are subjected to torture or extra- 139 judicial killing or detention on the basis of information gathered by 140 state agencies through information leakage in protocols. 142 This document details several 'common' threats to human rights, 143 indicating how each of these can lead to human rights violations/ 144 harms and present several examples of how these threats to human 145 rights materialize on the Internet. This threat modeling is inspired 146 by [RFC6973] Privacy Considerations for Internet Protocols, which is 147 based on security threat analysis. This method is a work in progress 148 and by no means a perfect solution for assessing human rights risks 149 in Internet protocols and systems. Certain specific human rights 150 threats are indirectly considered in Internet protocols as part of 151 the security considerations [BCP72], but privacy considerations 152 [RFC6973] or reviews, let alone human rights impact assessments of 153 protocols are not standardized or implemented. 155 Many threats, enablers and risks are linked to different rights. 156 This is not unsurprising if one takes into account that human rights 157 are interrelated, interdependent and indivisible. Here however we're 158 not discussing all human rights because not all human rights are 159 relevant to ICTs in general and protocols and standards in particular 160 [Bless]: "The main source of the values of human rights is the 161 International Bill of Human Rights that is composed of the Universal 162 Declaration of Human Rights [UDHR] along with the International 163 Covenant on Civil and Political Rights [ICCPR] and the International 164 Covenant on Economic, Social and Cultural Rights [ICESCR]. In the 165 light of several cases of Internet censorship, the Human Rights 166 Council Resolution 20/8 was adopted in 2012 [UNHRC2016], affirming ". 167 . . that the same rights that people have offline must also be 168 protected online. . . " . In 2015, the Charter of Human Rights and 169 Principles for the Internet [IRP] was developed and released. 170 According to these documents, some examples of human rights relevant 171 for ICT systems are human dignity (Art. 1 UDHR), non-discrimination 172 (Art. 2), rights to life, liberty and security (Art. 3), freedom of 173 opinion and expression (Art. 19), freedom of assembly and association 174 (Art. 20), rights to equal protection, legal remedy, fair trial, due 175 process, presumed innocent (Art. 7-11), appropriate social and 176 international order (Art. 28), participation in public affairs (Art. 177 21), participation in cultural life, protection of the moral and 178 material interests resulting from any scientific, literary or 179 artistic production of which [they are] the author (Art. 27), and 180 privacy (Art. 12)." A partial catalog of human rights related to 181 Information and Communications technologies, including economic 182 rights, can be found in [Hill2014]. 184 This is by no means an attempt to exclude specific rights or 185 prioritize some rights over others. If other rights seem relevant, 186 please contact the authors. 188 3.2. Conducting human rights reviews 190 Human rights reviews can take place in different parts of the 191 development process of an Internet Draft. However, generally 192 speaking, it is easier to influence the development of a technology 193 at earlier stages than at later stages. This does not mean that 194 reviews at last-call are not relevant, but they are less likely to 195 result in significant changes in the reviewed document. 197 Methods for analyzing technology for specific human rights impacts 198 are still quite nascent. Currently five methods have been explored 199 by the Human Rights Review Team, often in conjunction with each 200 other: 202 3.2.1. Analyzing drafts based on guidelines for human rights 203 considerations model 205 This analysis of Internet-Drafts uses the model as described below. 206 The outlined categories and questions are used to review an Internet 207 Draft an generally the review is also presented in that order. The 208 advantage of this is that it provides a known overview, and document 209 authors can go back to this document as well as [RFC8280] to 210 understand the background and the context. 212 3.2.2. Analyzing drafts based on their perceived or speculated impact 214 When reviewing an Internet-Draft, specific human rights impacts might 215 become apparent by doing a close reading of the draft and seeking to 216 understand how it might affect networks or society. While less 217 structured than the straight use of the human rights considerations 218 model, this analysis might lead to new speculative understandings 219 between human rights and protocols. 221 3.2.3. Expert interviews 223 Interviews with document authors, active members of the Working 224 Group, or experts in the field can help explore the characteristics 225 of the protocol and their effects. There are two main advantages to 226 this approach: one the one hand, it allows the reviewer to gain a 227 deeper understanding of the (intended) workings of the protocol; on 228 the other hand, it also allows for the reviewer to start a discussion 229 with experts or even document authors about certain aspects, which 230 might help gain the review gain traction when it is published. 232 3.2.4. Interviews with impacted persons and communities 234 Protocols impact users of the Internet. There it might help the 235 review to understand how it impacts the people that use the protocol, 236 and the people whose lives are impacted by the protocol. Since human 237 rights should always be understood from the rightsholder, this 238 approach will improve the understanding of the real world effects of 239 the technology. At the same time, it can be hard to attribute 240 specific changes to a particular protocol, this is of course even 241 harder when a protocol has not been (widely) deployed. 243 3.2.5. Tracing impacts of implementations 245 When an Internet Draft is describing running code that has already 246 been implemented, the code could be analyzed either in an 247 experimental setting or on the Internet where its impact can be 248 observed. Other than reviewing a draft, this allows the reviewer to 249 understand how the document works in practice and potentially also 250 what unknown or unexpected effects the technology might have. 252 3.3. Guidelines for human rights considerations 254 This section provides guidance for document authors in the form of a 255 questionnaire about protocols and their (potential) impact. The 256 questionnaire may be useful at any point in the design process, 257 particularly after document authors have developed a high-level 258 protocol model as described in [RFC4101]. These guidelines do not 259 seek to replace any existing referenced specifications, but rather 260 contribute to them and look at the design process from a human rights 261 perspective. 263 Protocols and Internet Standard might benefit from a documented 264 discussion of potential human rights risks arising from potential 265 misapplications of the protocol or technology described in the RFC. 266 This might be coupled with an Applicability Statement for that RFC. 268 Note that the guidance provided in this section does not recommend 269 specific practices. The range of protocols developed in the IETF is 270 too broad to make recommendations about particular uses of data or 271 how human rights might be balanced against other design goals. 272 However, by carefully considering the answers to the following 273 questions, document authors should be able to produce a comprehensive 274 analysis that can serve as the basis for discussion on whether the 275 protocol adequately takes specific human rights threats into account. 276 This guidance is meant to help the thought process of a human rights 277 analysis; it does not provide specific directions for how to write a 278 human rights considerations section (following the example set in 279 [RFC6973]). 281 In considering these questions, authors will need to be aware of the 282 potential of technical advances or the passage of time to undermine 283 protections. In general, considerations of rights are likely to be 284 more effective if they are considered given a purpose and specific 285 use cases, rather than as abstract absolute goals. 287 3.3.1. Connectivity 289 Question(s): Does your protocol add application-specific functions to 290 intermediary nodes? Could this functionality be added to end nodes 291 instead of intermediary nodes? Is your protocol optimized for low 292 bandwidth and high latency connections? Could your protocol also be 293 developed in a stateless manner? 295 Explanation: The end-to-end principle [Saltzer] holds that 'the 296 intelligence is end to end rather than hidden in the network' 297 [RFC1958]. The end-to-end principle is important for the robustness 298 of the network and innovation. Such robustness of the network is 299 crucial to enabling human rights like freedom of expression. 301 Example: Middleboxes (which can be Content Delivery Networks, 302 Firewalls, NATs or other intermediary nodes that provide 'services' 303 besides routing) serve many legitimate purposes. However, protocols 304 relying on middleboxes can create potential for abuse, and 305 intentional and unintentional censoring, thereby influencing 306 individuals' ability to communicate online freely and privately. 308 Impacts: 310 - Right to freedom of expression 312 - Right to freedom of assembly and association 314 3.3.2. Privacy 316 Question(s): Did you have a look at the Guidelines in the Privacy 317 Considerations for Internet Protocols [RFC6973] section 7? Does your 318 protocol maintain the confidentiality of metadata? Could your 319 protocol counter traffic analysis? Does your protocol adhere to data 320 minimization principles? Does your document identify potentially 321 sensitive data logged by your protocol and/or for how long that needs 322 to be retained for technical reasons? 324 Explanation: Privacy refers to the right of an entity (normally a 325 person), acting in its own behalf, to determine the degree to which 326 it will interact with its environment, including the degree to which 327 the entity is willing to share its personal information with others. 328 [RFC4949]. If a protocol provides insufficient privacy protection it 329 may have a negative impact on freedom of expression as users self- 330 censor for fear of surveillance, or find themselves unable to express 331 themselves freely. 333 Example: See [RFC6973] 335 Impacts: 337 - Right to freedom of expression 339 - Right to non-discrimination 341 3.3.3. Content agnosticism 343 Question(s): If your protocol impacts packet handling, does it use 344 user data (packet data that is not included in the header)? Is it 345 making decisions based on the payload of the packet? Does your 346 protocol prioritize certain content or services over others in the 347 routing process? Is the protocol transparent about the 348 prioritization that is made (if any)? 350 Explanation: Content agnosticism refers to the notion that network 351 traffic is treated identically regardless of payload, with some 352 exception where it comes to effective traffic handling, for instance 353 where it comes to delay tolerant or delay sensitive packets, based on 354 the header. 356 Example: Content agnosticism prevents payload-based discrimination 357 against packets. This is important because changes to this principle 358 can lead to a two-tiered Internet, where certain packets are 359 prioritized over others on the basis of their content. Effectively 360 this would mean that although all users are entitled to receive their 361 packets at a certain speed, some users become more equal than others. 363 Impacts: 365 - Right to freedom of expression 367 - Right to non-discrimination 369 - Right to equal protection 371 3.3.4. Security 373 Question(s): Did you have a look at Guidelines for Writing RFC Text 374 on Security Considerations [BCP72]? Have you found any attacks that 375 are somewhat related to your protocol yet considered out of scope of 376 your document? Would these attacks be pertinent to the human rights 377 enabling features of the Internet (as described throughout this 378 document)? 380 Explanation: Security is not a single monolithic property of a 381 protocol or system, but rather a series of related but somewhat 382 independent properties. Not all of these properties are required for 383 every application. Since communications are carried out by systems 384 and access to systems is through communications channels, security 385 goals obviously interlock, but they can also be independently 386 provided. [BCP72]. 388 Example: See [BCP72]. 390 Impacts: 392 - Right to freedom of expression 394 - Right to freedom of assembly and association 396 - Right to non-discrimination 398 - Right to security 400 3.3.5. Internationalization 402 Question(s): Does your protocol have text strings that have to be 403 understood or entered by humans? Does your protocol allow Unicode? 404 If so, do you accept texts in one charset (which must be UTF-8), or 405 several (which is dangerous for interoperability)? If character sets 406 or encodings other than UTF-8 are allowed, does your protocol mandate 407 a proper tagging of the charset? Did you have a look at [RFC6365]? 409 Explanation: Internationalization refers to the practice of making 410 protocols, standards, and implementations usable in different 411 languages and scripts (see Localization). In the IETF, 412 internationalization means to add or improve the handling of non- 413 ASCII text in a protocol. [RFC6365] A different perspective, more 414 appropriate to protocols that are designed for global use from the 415 beginning, is the definition used by W3C: 417 "Internationalization is the design and development of a 418 product, application or document content that enables easy 419 localization for target audiences that vary in culture, region, 420 or language." {{W3Ci18nDef}} 422 Many protocols that handle text only handle one charset (US-ASCII), 423 or leave the question of what coded character set and encoding are 424 used up to local guesswork (which leads, of course, to 425 interoperability problems). If multiple charsets are permitted, they 426 must be explicitly identified [RFC2277]. Adding non-ASCII text to a 427 protocol allows the protocol to handle more scripts, hopefully 428 representing users across the world. In today's world, that is 429 normally best accomplished by allowing Unicode encoded in UTF-8 only. 431 In the current IETF policy [RFC2277], internationalization is aimed 432 at user-facing strings, not protocol elements, such as the verbs used 433 by some text-based protocols. (Do note that some strings are both 434 content and protocol elements, such as the identifiers.) If IETF 435 wants the Internet to be a global network of networks, the protocols 436 should work with languages apart from English and character sets 437 apart from Latin characters. It is therefore crucial that at least 438 the content carried by the protocol can be in any script, and that 439 all scripts are treated equally. 441 Example: See localization 443 Impacts: 445 - Right to freedom of expression 447 - Right to political participation 449 - Right to participate in cultural life, arts and science 451 3.3.6. Censorship resistance 453 Question(s): Does your protocol make it apparent or transparent when 454 access to a resource it restricted? Can your protocol contribute to 455 filtering in a way it could be implemented to censor data or 456 services? Could this be designed to ensure this doesn't happen? 457 Does your protocol introduce new identifiers or reuse existing 458 identifiers (e.g. MAC addresses) that might be associated with 459 persons or content? 461 Explanation: Censorship resistance refers to the methods and measures 462 to prevent Internet censorship. 464 Example: In the development of the IPv6 protocol, it was discussed to 465 embed a Media Access Control (MAC) address into unique IP addresses. 466 This would make it possible for 'eavesdroppers and other information 467 collectors to identify when different addresses used in different 468 transactions actually correspond to the same node. This is why 469 Privacy Extensions for Stateless Address Autoconfiguration in IPv6 470 have been introduced. [RFC4941] 471 Identifiers of content exposed within a protocol might be used to 472 facilitate censorship, as in the case of Application Layer based 473 censorship, which affects protocols like HTTP. In HTTP, denial or 474 restriction of access can be made apparent by the use of status code 475 451, which allows server operators to operate with greater 476 transparency in circumstances where issues of law or public policy 477 affect their operation [RFC7725]. 479 Impacts: 481 - Right to freedom of expression 483 - Right to political participation 485 - Right to participate in cultural life, arts and science 487 - Right to freedom of assembly and association 489 3.3.7. Open Standards 491 Question(s): Is your protocol fully documented in a way that it could 492 be easily implemented, improved, built upon and/or further developed? 493 Do you depend on proprietary code for the implementation, running or 494 further development of your protocol? Does your protocol favor a 495 particular proprietary specification over technically-equivalent 496 competing specification(s), for instance by making any incorporated 497 vendor specification "required" or "recommended" [RFC2026]? Do you 498 normatively reference another standard that is not available without 499 cost (and could you do without it)? Are you aware of any patents 500 that would prevent your standard from being fully implemented 501 [RFC8179] [RFC6701]? 503 Explanation: The Internet was able to be developed into the global 504 network of networks because of the existence of open, non-proprietary 505 standards [Zittrain]. They are crucial for enabling 506 interoperability. Yet, open standards are not explicitly defined 507 within the IETF. On the subject, [RFC2026] states: "Various national 508 and international standards bodies, such as ANSI, ISO, IEEE, and ITU- 509 T, develop a variety of protocol and service specifications that are 510 similar to Technical Specifications defined at the IETF. National 511 and international groups also publish "implementors' agreements" that 512 are analogous to Applicability Statements, capturing a body of 513 implementation-specific detail concerned with the practical 514 application of their standards. All of these are considered to be 515 "open external standards" for the purposes of the Internet Standards 516 Process." Similarly, [RFC3935] does not define open standards but 517 does emphasize the importance of an "open process", i.e. "any 518 interested person can participate in the work, know what is being 519 decided, and make his or her voice heard on the issue." 521 Open standards are important as they allow for permissionless 522 innovation, which is important to maintain the freedom and ability to 523 freely create and deploy new protocols on top of the communications 524 constructs that currently exist. It is at the heart of the Internet 525 as we know it, and to maintain its fundamentally open nature, we need 526 to be mindful of the need for developing open standards. 528 All standards that need to be normatively implemented should be 529 freely available and with reasonable protection for patent 530 infringement claims, so it can also be implemented in open source or 531 free software. Patents have often held back open standardization or 532 been used against those deploying open standards, particularly in the 533 domain of cryptography [newegg]. An exemption of this is sometimes 534 made when a protocol is standardized that normatively relies on 535 specifications produced by others SDOs that are not freely available. 536 Patents in open standards or in normative references to other 537 standards should have a patent disclosure [notewell], royalty-free 538 licensing [patentpolicy], or some other form of fair, reasonable and 539 non-discriminatory terms. 541 Example: [RFC6108] describes a system for providing critical end-user 542 notifications to web browsers, which has been deployed by Comcast, an 543 Internet Service Provider (ISP). Such a notification system is being 544 used to provide near-immediate notifications to customers, such as to 545 warn them that their traffic exhibits patterns that are indicative of 546 malware or virus infection. There are other proprietary systems that 547 can perform such notifications, but those systems utilize Deep Packet 548 Inspection (DPI) technology. In contrast, that document describes a 549 system that does not rely upon DPI, and is instead based on open IETF 550 standards and open source applications. 552 Impacts: 554 - Right to freedom of expression 556 - Right to participate in cultural life, arts and science 558 3.3.8. Heterogeneity Support 560 Question(s): Does your protocol support heterogeneity by design? 561 Does your protocol allow for multiple types of hardware? Does your 562 protocol allow for multiple types of application protocols? Is your 563 protocol liberal in what it receives and handles? Will it remain 564 usable and open if the context changes? Does your protocol allow 565 there to be well-defined extension points? Do these extension points 566 allow for open innovation? 568 Explanation: The Internet is characterized by heterogeneity on many 569 levels: devices and nodes, router scheduling algorithms and queue 570 management mechanisms, routing protocols, levels of multiplexing, 571 protocol versions and implementations, underlying link layers (e.g., 572 point-to-point, multi-access links, wireless, FDDI, etc.), in the 573 traffic mix and in the levels of congestion at different times and 574 places. Moreover, as the Internet is composed of autonomous 575 organizations and Internet service providers, each with their own 576 separate policy concerns, there is a large heterogeneity of 577 administrative domains and pricing structures. As a result, the 578 heterogeneity principle proposed in [RFC1958] needs to be supported 579 by design [FIArch]. 581 Example: Heterogeneity is inevitable and needs be supported by 582 design. Multiple types of hardware must be allowed for, e.g. 583 transmission speeds differing by at least 7 orders of magnitude, 584 various computer word lengths, and hosts ranging from memory-starved 585 microprocessors up to massively parallel supercomputers. Multiple 586 types of application protocols must be allowed for, ranging from the 587 simplest such as remote login up to the most complex such as commit 588 protocols for distributed databases. [RFC1958]. 590 Impacts: 592 - Right to freedom of expression 594 - Right to political participation 596 3.3.9. Pseudonymity 598 Question(s): Have you considered the Privacy Considerations for 599 Internet Protocols [RFC6973], especially section 6.1.2 ? Does the 600 protocol collect personally derived data? Does the protocol generate 601 or process anything that can be, or be tightly correlated with, 602 personally identifiable information? Does the protocol utilize data 603 that is personally-derived, i.e. derived from the interaction of a 604 single person, or their device or address? Does this protocol 605 generate personally derived data, and if so how will that data be 606 handled? 608 Explanation: Pseudonymity - the ability to use a persistent 609 identifier not linked to one's offline identity - is an important 610 feature for many end-users, as it allows them different degrees of 611 disguised identity and privacy online. 613 Example: While designing a standard that exposes personal data, it is 614 important to consider ways to mitigate the obvious impacts. While 615 pseudonyms cannot be simply reverse engineered - some early 616 approaches simply took approaches such as simple hashing of IP 617 addresses, these could then be simply reversed by generating a hash 618 for each potential IP address and comparing it to the pseudonym - 619 limiting the exposure of personal data remains important. 621 Pseudonymity means using a pseudonym instead of one's "real" name. 622 There are many reasons for users to use pseudonyms, for instance to: 623 hide their gender, protect themselves against harassment, protect 624 their families' privacy, frankly discuss sexuality, or develop a 625 artistic or journalistic persona without repercussions from an 626 employer, (potential) customers, or social surrounding. 627 [geekfeminism] The difference between anonymity and pseudonymity is 628 that a pseudonym often is persistent. "Pseudonymity is strengthened 629 when less personal data can be linked to the pseudonym; when the same 630 pseudonym is used less often and across fewer contexts; and when 631 independently chosen pseudonyms are more frequently used for new 632 actions (making them, from an observer's or attacker's perspective, 633 unlinkable)." [RFC6973] 635 Impacts: 637 - Right to non-discrimination 639 - Right to freedom of assembly and association 641 3.3.10. Accessibility 643 Question(s): Is your protocol designed to provide an enabling 644 environment for people who are not able-bodied? Have you looked at 645 the W3C Web Accessibility Initiative for examples and guidance? 647 Explanation: Sometimes in the design of protocols, websites, web 648 technologies, or web tools, barriers are created that exclude people 649 from using the Web. The Internet should be designed to work for all 650 people, whatever their hardware, software, language, culture, 651 location, or physical or mental ability. When the Internet 652 technologies meet this goal, it will be accessible to people with a 653 diverse range of hearing, movement, sight, and cognitive ability. 654 [W3CAccessibility] 656 Example: The HTML protocol as defined in [HTML5] specifically 657 requires that every image must have an alt attribute (with a few 658 exceptions) to ensure images are accessible for people that cannot 659 themselves decipher non-text content in web pages. 661 Impacts: 663 - Right to non-discrimination 665 - Right to freedom of assembly and association 667 - Right to education 669 - Right to political participation 671 3.3.11. Localization 673 Question(s): Does your protocol uphold the standards of 674 internationalization? Have you made any concrete steps towards 675 localizing your protocol for relevant audiences? 677 Explanation: Localization refers to the adaptation of a product, 678 application or document content to meet the language, cultural and 679 other requirements of a specific target market (a locale) 680 [W3Ci18nDef]. It is also described as the practice of translating an 681 implementation to make it functional in a specific language or for 682 users in a specific locale (see Internationalization). 684 Example: The Internet is a global medium, but many of its protocols 685 and products are developed with a certain audience in mind, that 686 often share particular characteristics like knowing how to read and 687 write in ASCII and knowing English. This limits the ability of a 688 large part of the world's online population from using the Internet 689 in a way that is culturally and linguistically accessible. An 690 example of a protocol that has taken into account the view that 691 individuals like to have access to data in their native language can 692 be found in [RFC5646]. This protocol labels the information content 693 with an identifier for the language in which it is written. And this 694 allows information to be presented in more than one language. 696 Impacts: 698 - Right to non-discrimination 700 - Right to participate in cultural life, arts and science 702 - Right to freedom of expression 704 3.3.12. Decentralization 706 Question(s): Can your protocol be implemented without a single point 707 of control? If applicable, can your protocol be deployed in a 708 federated manner? What is the potential for discrimination against 709 users of your protocol? How can your protocol be used to implicate 710 users? Does your protocol create additional centralized points of 711 control? 713 Explanation: Decentralization is one of the central technical 714 concepts of the architecture of the networks, and embraced as such by 715 the IETF [RFC3935]. It refers to the absence or minimization of 716 centralized points of control, a feature that is assumed to make it 717 easy for new users to join and new uses to unfold [Brown]. It also 718 reduces issues surrounding single points of failure, and distributes 719 the network such that it continues to function even if one or several 720 nodes are disabled. With the commercialization of the Internet in 721 the early 1990s, there has been a slow move away from 722 decentralization, to the detriment of the technical benefits of 723 having a decentralized Internet. 725 Example: The bits traveling the Internet are increasingly susceptible 726 to monitoring and censorship, from both governments and Internet 727 service providers, as well as third (malicious) parties. The ability 728 to monitor and censor is further enabled by the increased 729 centralization of the network that creates central infrastructure 730 points that can be tapped in to. The creation of peer-to-peer 731 networks and the development of voice-over-IP protocols using peer- 732 to-peer technology in combination with distributed hash table (DHT) 733 for scalability are examples of how protocols can preserve 734 decentralization [Pouwelse]. 736 Impacts: 738 - Right to freedom of expression 740 - Right to freedom of assembly and association 742 3.3.13. Reliability 744 Question(s): Is your protocol fault tolerant? Does it downgrade 745 gracefully? Can your protocol resist malicious degradation attempts? 746 Do you have a documented way to announce degradation? Do you have 747 measures in place for recovery or partial healing from failure? Can 748 your protocol maintain dependability and performance in the face of 749 unanticipated changes or circumstances? 751 Explanation: Reliability ensures that a protocol will execute its 752 function consistently and error resistant as described, and function 753 without unexpected result. A system that is reliable degenerates 754 gracefully and will have a documented way to announce degradation. 755 It also has mechanisms to recover from failure gracefully, and if 756 applicable, allow for partial healing. It is important here to draw 757 a distinction between random degradation and malicious degradation. 758 Many current attacks against TLS, for example, exploit TLS' ability 759 to gracefully downgrade to older cipher suites - from a functional 760 perspective, this is good; from a security perspective, this can be 761 very bad. As with confidentiality, the growth of the Internet and 762 fostering innovation in services depends on users having confidence 763 and trust [RFC3724] in the network. For reliability, it is necessary 764 that services notify the users if a delivery fails. In the case of 765 real-time systems in addition to the reliable delivery the protocol 766 needs to safeguard timeliness. 768 Example: In the modern IP stack structure, a reliable transport layer 769 requires an indication that transport processing has successfully 770 completed, such as given by TCP's ACK message [RFC0793], and not 771 simply an indication from the IP layer that the packet arrived. 772 Similarly, an application layer protocol may require an application- 773 specific acknowledgment that contains, among other things, a status 774 code indicating the disposition of the request (See [RFC3724]). 776 Impacts: 778 - Right to freedom of expression 780 - Right to security 782 3.3.14. Confidentiality 784 Question(s): Does this protocol expose information related to 785 identifiers or data? If so, does it do so to each other protocol 786 entity (i.e., recipients, intermediaries, and enablers) [RFC6973]? 787 What options exist for protocol implementers to choose to limit the 788 information shared with each entity? What operational controls are 789 available to limit the information shared with each entity? 791 What controls or consent mechanisms does the protocol define or 792 require before personal data or identifiers are shared or exposed via 793 the protocol? If no such mechanisms or controls are specified, is it 794 expected that control and consent will be handled outside of the 795 protocol? 797 Does the protocol provide ways for initiators to share different 798 pieces of information with different recipients? If not, are there 799 mechanisms that exist outside of the protocol to provide initiators 800 with such control? 802 Does the protocol provide ways for initiators to limit the sharing or 803 express individuals' preferences to recipients or intermediaries with 804 regard to the collection, use, or disclosure of their personal data? 805 If not, are there mechanisms that exist outside of the protocol to 806 provide users with such control? Is it expected that users will have 807 relationships that govern the use of the information (contractual or 808 otherwise) with those who operate these intermediaries? Does the 809 protocol prefer encryption over clear text operation? 811 Explanation: Confidentiality refers to keeping your data secret from 812 unintended listeners [BCP72]. The growth of the Internet depends on 813 users having confidence that the network protects their personal data 814 [RFC1984]. 816 Example: Protocols that do not encrypt their payload make the entire 817 content of the communication available to the idealized attacker 818 along their path. Following the advice in [RFC3365], most such 819 protocols have a secure variant that encrypts the payload for 820 confidentiality, and these secure variants are seeing ever-wider 821 deployment. A noteworthy exception is DNS [RFC1035], as DNSSEC 822 [RFC4033] does not have confidentiality as a requirement. This 823 implies that, in the absence of the use of more recent standards like 824 DNS over TLS [RFC7858] or DNS over HTTPS [RFC8484], all DNS queries 825 and answers generated by the activities of any protocol are available 826 to the attacker. When store-and-forward protocols are used (e.g., 827 SMTP [RFC5321]), intermediaries leave this data subject to 828 observation by an attacker that has compromised these intermediaries, 829 unless the data is encrypted end-to-end by the application-layer 830 protocol or the implementation uses an encrypted store for this data 831 [RFC7624]. 833 Impacts: 835 - Right to privacy 837 - Right to security 839 3.3.15. Integrity 841 Question(s): Does your protocol maintain, assure and/or verify the 842 accuracy of payload data? Does your protocol maintain and assure the 843 consistency of data? Does your protocol in any way allow for the 844 data to be (intentionally or unintentionally) altered? 846 Explanation: Integrity refers to the maintenance and assurance of the 847 accuracy and consistency of data to ensure it has not been 848 (intentionally or unintentionally) altered. 850 Example: Integrity verification of data is important to prevent 851 vulnerabilities and attacks from on-path attackers. These attacks 852 happen when a third party (often for malicious reasons) intercepts a 853 communication between two parties, inserting themselves in the middle 854 changing the content of the data. In practice this looks as follows: 856 Alice wants to communicate with Bob. 857 Corinne forges and sends a message to Bob, impersonating Alice. 858 Bob cannot see the data from Alice was altered by Corinne. 859 Corinne intercepts and alters the communication as it is sent between 860 Alice and Bob. 861 Corinne is able to control the communication content. 863 Impacts: 865 - Right to freedom of expression 867 - Right to security 869 3.3.16. Authenticity 871 Question(s): Do you have sufficient measures to confirm the truth of 872 an attribute of a single piece of data or entity? Can the attributes 873 get garbled along the way (see security)? If relevant, have you 874 implemented IPsec, DNSsec, HTTPS and other Standard Security Best 875 Practices? 877 Explanation: Authenticity ensures that data does indeed come from the 878 source it claims to come from. This is important to prevent certain 879 attacks or unauthorized access and use of data. 881 At the same time, authentication should not be used as a way to 882 prevent heterogeneity support, as is often done for vendor lock-in or 883 digital rights management. 885 Example: Authentication of data is important to prevent 886 vulnerabilities, and attacks from on-path attackers. These attacks 887 happen when a third party (often for malicious reasons) intercepts a 888 communication between two parties, inserting themselves in the middle 889 and posing as both parties. In practice this looks as follows: 891 Alice wants to communicate with Bob. 892 Alice sends data to Bob. 893 Corinne intercepts the data sent to Bob. 894 Corinne reads (and potentially alters) the message to Bob. 895 Bob cannot see the data did not come from Alice but from Corinne. 897 When there is proper authentication the scenario would be as follows: 899 Alice wants to communicate with Bob. 900 Alice sends data to Bob. 902 Corinne intercepts the data sent to Bob. 903 Corinne reads and alters the message to Bob. 904 Bob can see the data did not come from Alice. 906 Impacts: 908 - Right to privacy 910 - Right to freedom of expression 912 - Right to security 914 3.3.17. Adaptability 916 Question(s): Is your protocol written in such a way that is would be 917 easy for other protocols to be developed on top of it, or to interact 918 with it? Does your protocol impact permissionless innovation? (See 919 Connectivity) 921 Explanation: Adaptability is closely interrelated with permissionless 922 innovation: both maintain the freedom and ability to freely create 923 and deploy new protocols on top of the communications constructs that 924 currently exist. It is at the heart of the Internet as we know it, 925 and to maintain its fundamentally open nature, we need to be mindful 926 of the impact of protocols on maintaining or reducing permissionless 927 innovation to ensure the Internet can continue to develop. 929 Example: WebRTC generates audio and/or video data. In order to 930 ensure that WebRTC can be used in different locations by different 931 parties, it is important that standard Javascript APIs are developed 932 to support applications from different voice service providers. 933 Multiple parties will have similar capabilities, in order to ensure 934 that all parties can build upon existing standards these need to be 935 adaptable, and allow for permissionless innovation. 937 Impacts: 939 - Right to education 941 - Freedom of expression 943 - Freedom of assembly and association 945 3.3.18. Outcome Transparency 947 Question(s): Are the effects of your protocol fully and easily 948 comprehensible, including with respect to unintended consequences of 949 protocol choices? 950 Explanation: Certain technical choices may have unintended 951 consequences. 953 Example: Lack of authenticity may lead to lack of integrity and 954 negative externalities, of which spam is an example. Lack of data 955 that could be used for billing and accounting can lead to so-called 956 "free" arrangements which obscure the actual costs and distribution 957 of the costs, for example the barter arrangements that are commonly 958 used for Internet interconnection; and the commercial exploitation of 959 personal data for targeted advertising which is the most common 960 funding model for the so-called "free" services such as search 961 engines and social networks. Other unexpected outcomes might not be 962 technical, but rather architectural, social or economical. 964 Impacts: 966 - Freedom of expression 968 - Privacy 970 - Freedom of assembly and association 972 - Access to information 974 3.3.19. Anonymity 976 Question(s): Does your protocol make use of persistent identifiers? 977 Can it be done without them? Did you have a look at the Privacy 978 Considerations for Internet Protocols [RFC6973], especially section 979 6.1.1 of that document? 981 Explanation: Anonymity refers to the condition of an identity being 982 unknown or concealed [RFC4949]. Even though full anonymity is hard 983 to achieve, it is a non-binary concept. Making pervasive monitoring 984 and tracking harder is important for many users as well as for the 985 IETF [RFC7258]. Achieving a higher level of anonymity is an 986 important feature for many end-users, as it allows them different 987 degrees of privacy online. Anonymity is an inherent part of the 988 right to freedom of opinion and expression and the right to privacy. 989 Avoid adding identifiers, options or configurations that create or 990 might lead to patterns or regularities that are not explicitly 991 required by the protocol. 993 If your protocol collects data and distributes it (see [RFC6235]), 994 you should anonymize the data, but keep in mind that "anonymizing" 995 data is notoriously hard. Do not think that just dropping the last 996 byte of an IP address "anonymizes" data. If your protocol allows for 997 identity management, there should be a clear barrier between the 998 identities to ensure that they cannot (easily) be associated with 999 each other. 1001 Often protocols expose personal data, it is important to consider 1002 ways to mitigate the obvious privacy impacts. A protocol that uses 1003 data that could help identify a sender (items of interest) should be 1004 protected from third parties. For instance, if one wants to hide the 1005 source/destination IP addresses of a packet, the use of IPsec in 1006 tunneling mode (e.g., inside a virtual private network) can be 1007 helpful to protect from third parties likely to eavesdrop packets 1008 exchanged between the tunnel endpoints. 1010 Example: An example is DHCP where sending a persistent identifier as 1011 the client name was not mandatory but, in practice, done by many 1012 implementations, before [RFC7844]. 1014 Impacts: 1016 - Right to non-discrimination 1018 - Right to political participation 1020 - Right to freedom of assembly and association 1022 - Right to security 1024 4. Document Status 1026 This RG document is currently documenting best practices and 1027 guidelines for human rights reviews of networking protocols and other 1028 Internet-Drafts and RFCs 1030 5. Acknowledgements 1032 Thanks to: 1034 - Corinne Cath for work on [RFC8280]. 1036 - Theresa Engelhard, Joe Hall, Avri Doria and the hrpc list for 1037 reviews and suggestions. 1039 - The Human Rights Review Team for implementing and improving the 1040 guidelines. 1042 6. Security Considerations 1044 As this document concerns a research document, there are no security 1045 considerations. 1047 7. IANA Considerations 1049 This document has no actions for IANA. 1051 8. Research Group Information 1053 The discussion list for the IRTF Human Rights Protocol Considerations 1054 Research Group is located at the e-mail address hrpc@ietf.org [1]. 1055 Information on the group and information on how to subscribe to the 1056 list is at https://www.irtf.org/mailman/listinfo/hrpc [2] 1058 Archives of the list can be found at: https://www.irtf.org/mail- 1059 archive/web/hrpc/current/index.html [3] 1061 9. References 1063 9.1. Informative References 1065 [BCP72] IETF, "Guidelines for Writing RFC Text on Security 1066 Considerations", 2003, 1067 . 1069 [Bless] Bless, R. and C. Orwat, "Values and Networks", 2015. 1071 [Brown] Brown, I. and M. Ziewitz, "A Prehistory of Internet 1072 Governance", Research Handbook on Governance of the 1073 Internet. Cheltenham, Edward Elgar. , 2013. 1075 [FIArch] "Future Internet Design Principles", January 2012, 1076 . 1079 [geekfeminism] 1080 Geek Feminism Wiki, "Pseudonymity", 2015, 1081 . 1083 [Hill2014] 1084 Hill, R., "Partial Catalog of Human Rights Related to ICT 1085 Activities", 2014, 1086 . 1088 [HTML5] W3C, "HTML5", 2014, . 1090 [ICCPR] United Nations General Assembly, "International Covenant 1091 on Civil and Political Rights", 1976, 1092 . 1095 [ICESCR] United Nations General Assembly, "International Covenant 1096 on Economic, Social and Cultural Rights", 1966, 1097 . 1100 [IRP] Internet Rights and Principles Dynamic Coalition, "10 1101 Internet Rights & Principles", 2014, 1102 . 1106 [newegg] Mullin, J., "Newegg on trial: Mystery company TQP rewrites 1107 the history of encryption", 2013, . 1111 [notewell] 1112 IETF, "Note Well", 2015, 1113 . 1115 [patentpolicy] 1116 W3C, "W3C Patent Policy", 2004, 1117 . 1119 [Penney] Penney, J., "Chilling Effects: Online Surveillance and 1120 Wikipedia Use", 2016, . 1123 [Pouwelse] 1124 Pouwelse, Ed, J., "Media without censorship", 2012, 1125 . 1128 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1129 RFC 793, DOI 10.17487/RFC0793, September 1981, 1130 . 1132 [RFC1035] Mockapetris, P., "Domain names - implementation and 1133 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1134 November 1987, . 1136 [RFC1958] Carpenter, B., Ed., "Architectural Principles of the 1137 Internet", RFC 1958, DOI 10.17487/RFC1958, June 1996, 1138 . 1140 [RFC1984] IAB and IESG, "IAB and IESG Statement on Cryptographic 1141 Technology and the Internet", BCP 200, RFC 1984, 1142 DOI 10.17487/RFC1984, August 1996, 1143 . 1145 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 1146 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, 1147 . 1149 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 1150 Languages", BCP 18, RFC 2277, DOI 10.17487/RFC2277, 1151 January 1998, . 1153 [RFC3365] Schiller, J., "Strong Security Requirements for Internet 1154 Engineering Task Force Standard Protocols", BCP 61, 1155 RFC 3365, DOI 10.17487/RFC3365, August 2002, 1156 . 1158 [RFC3724] Kempf, J., Ed., Austein, R., Ed., and IAB, "The Rise of 1159 the Middle and the Future of End-to-End: Reflections on 1160 the Evolution of the Internet Architecture", RFC 3724, 1161 DOI 10.17487/RFC3724, March 2004, 1162 . 1164 [RFC3935] Alvestrand, H., "A Mission Statement for the IETF", 1165 BCP 95, RFC 3935, DOI 10.17487/RFC3935, October 2004, 1166 . 1168 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1169 Rose, "DNS Security Introduction and Requirements", 1170 RFC 4033, DOI 10.17487/RFC4033, March 2005, 1171 . 1173 [RFC4101] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101, 1174 DOI 10.17487/RFC4101, June 2005, 1175 . 1177 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1178 Extensions for Stateless Address Autoconfiguration in 1179 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 1180 . 1182 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1183 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 1184 . 1186 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 1187 DOI 10.17487/RFC5321, October 2008, 1188 . 1190 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying 1191 Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, 1192 September 2009, . 1194 [RFC6108] Chung, C., Kasyanov, A., Livingood, J., Mody, N., and B. 1195 Van Lieu, "Comcast's Web Notification System Design", 1196 RFC 6108, DOI 10.17487/RFC6108, February 2011, 1197 . 1199 [RFC6235] Boschi, E. and B. Trammell, "IP Flow Anonymization 1200 Support", RFC 6235, DOI 10.17487/RFC6235, May 2011, 1201 . 1203 [RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in 1204 Internationalization in the IETF", BCP 166, RFC 6365, 1205 DOI 10.17487/RFC6365, September 2011, 1206 . 1208 [RFC6701] Farrel, A. and P. Resnick, "Sanctions Available for 1209 Application to Violators of IETF IPR Policy", RFC 6701, 1210 DOI 10.17487/RFC6701, August 2012, 1211 . 1213 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 1214 Morris, J., Hansen, M., and R. Smith, "Privacy 1215 Considerations for Internet Protocols", RFC 6973, 1216 DOI 10.17487/RFC6973, July 2013, 1217 . 1219 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1220 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 1221 2014, . 1223 [RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., 1224 Trammell, B., Huitema, C., and D. Borkmann, 1225 "Confidentiality in the Face of Pervasive Surveillance: A 1226 Threat Model and Problem Statement", RFC 7624, 1227 DOI 10.17487/RFC7624, August 2015, 1228 . 1230 [RFC7725] Bray, T., "An HTTP Status Code to Report Legal Obstacles", 1231 RFC 7725, DOI 10.17487/RFC7725, February 2016, 1232 . 1234 [RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity 1235 Profiles for DHCP Clients", RFC 7844, 1236 DOI 10.17487/RFC7844, May 2016, 1237 . 1239 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 1240 and P. Hoffman, "Specification for DNS over Transport 1241 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 1242 2016, . 1244 [RFC8179] Bradner, S. and J. Contreras, "Intellectual Property 1245 Rights in IETF Technology", BCP 79, RFC 8179, 1246 DOI 10.17487/RFC8179, May 2017, 1247 . 1249 [RFC8280] ten Oever, N. and C. Cath, "Research into Human Rights 1250 Protocol Considerations", RFC 8280, DOI 10.17487/RFC8280, 1251 October 2017, . 1253 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 1254 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 1255 . 1257 [Saltzer] Saltzer, J., Reed, D., and D. Clark, "End-to-End Arguments 1258 in System Design", ACM TOCS, Vol 2, Number 4, November 1259 1984, pp 277-288. , 1984. 1261 [UDHR] United Nations General Assembly, "The Universal 1262 Declaration of Human Rights", 1948, 1263 . 1265 [UNHRC2016] 1266 United Nations Human Rights Council, "UN Human Rights 1267 Council Resolution "The promotion, protection and 1268 enjoyment of human rights on the Internet" (A/HRC/32/ 1269 L.20)", 2016, . 1273 [W3CAccessibility] 1274 W3C, "Accessibility", 2015, 1275 . 1277 [W3Ci18nDef] 1278 W3C, "Localization vs. Internationalization", 2010, 1279 . 1281 [Zittrain] 1282 Zittrain, J., "The Future of the Internet - And How to 1283 Stop It", Yale University Press , 2008, 1284 . 1287 9.2. URIs 1289 [1] mailto:hrpc@ietf.org 1291 [2] https://www.irtf.org/mailman/listinfo/hrpc 1293 [3] https://www.irtf.org/mail-archive/web/hrpc/current/index.html 1295 Authors' Addresses 1297 Niels ten Oever 1298 University of Amsterdam 1300 EMail: mail@nielstenoever.net 1302 Gurshabad Grover 1303 Centre for Internet and Society 1305 EMail: gurshabad@cis-india.org