idnits 2.17.00 (12 Aug 2021) /tmp/idnits38754/draft-irtf-hrpc-guidelines-13.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: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. 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 document date (28 March 2022) is 47 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Duplicate reference: RFC2026, mentioned in 'RFC2026', was also mentioned in 'BCP9'. -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Human Rights Protocol Considerations Research Group G. Grover 3 Internet-Draft Centre for Internet and Society 4 Updates: 8280 (if approved) N. ten Oever 5 Intended status: Informational University of Amsterdam 6 Expires: 29 September 2022 28 March 2022 8 Guidelines for Human Rights Protocol and Architecture Considerations 9 draft-irtf-hrpc-guidelines-13 11 Abstract 13 This document sets guidelines for human rights considerations for 14 developers working on network protocols and architectures, similar to 15 the work done on the guidelines for privacy considerations [RFC6973]. 16 This is an updated version of the guidelines for human rights 17 considerations in [RFC8280]. 19 This document is not an Internet Standards Track specification; it is 20 published for informational purposes. 22 This informational document has consensus for publication from the 23 Internet Research Task Force (IRTF) Human Right Protocol 24 Considerations Research Group. It has been reviewed, tried, and 25 tested by both by the research group as well as by researchers and 26 practitioners from outside the research group. The research group 27 acknowledges that the understanding of the impact of internet 28 protocols and architecture on society is a developing practice and is 29 a body of research that is still in development. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on 29 September 2022. 48 Copyright Notice 50 Copyright (c) 2022 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 55 license-info) in effect on the date of publication of this document. 56 Please review these documents carefully, as they describe your rights 57 and restrictions with respect to this document. Code Components 58 extracted from this document must include Revised BSD License text as 59 described in Section 4.e of the Trust Legal Provisions and are 60 provided without warranty as described in the Revised BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Human rights threats . . . . . . . . . . . . . . . . . . . . 4 66 3. Conducting human rights reviews . . . . . . . . . . . . . . . 5 67 3.1. Analyzing drafts based on guidelines for human rights 68 considerations model . . . . . . . . . . . . . . . . . . 6 69 3.2. Analyzing drafts based on their perceived or speculated 70 impact . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 3.3. Expert interviews . . . . . . . . . . . . . . . . . . . . 6 72 3.4. Interviews with impacted persons and communities . . . . 6 73 3.5. Tracing impacts of implementations . . . . . . . . . . . 6 74 4. Guidelines for human rights considerations . . . . . . . . . 7 75 4.1. Connectivity . . . . . . . . . . . . . . . . . . . . . . 7 76 4.2. Reliability . . . . . . . . . . . . . . . . . . . . . . . 8 77 4.3. Content agnosticism . . . . . . . . . . . . . . . . . . . 9 78 4.4. Localization . . . . . . . . . . . . . . . . . . . . . . 10 79 4.5. Internationalization . . . . . . . . . . . . . . . . . . 11 80 4.6. Open Standards . . . . . . . . . . . . . . . . . . . . . 12 81 4.7. Heterogeneity Support . . . . . . . . . . . . . . . . . . 13 82 4.8. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 14 83 4.9. Authenticity . . . . . . . . . . . . . . . . . . . . . . 15 84 4.10. Confidentiality . . . . . . . . . . . . . . . . . . . . . 16 85 4.11. Security . . . . . . . . . . . . . . . . . . . . . . . . 17 86 4.12. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 18 87 4.13. Pseudonymity . . . . . . . . . . . . . . . . . . . . . . 18 88 4.14. Anonymity . . . . . . . . . . . . . . . . . . . . . . . . 19 89 4.15. Censorship resistance . . . . . . . . . . . . . . . . . . 20 90 4.16. Outcome Transparency . . . . . . . . . . . . . . . . . . 21 91 4.17. Adaptability . . . . . . . . . . . . . . . . . . . . . . 22 92 4.18. Accessibility . . . . . . . . . . . . . . . . . . . . . . 23 93 4.19. Decentralization . . . . . . . . . . . . . . . . . . . . 24 94 4.20. Remedy . . . . . . . . . . . . . . . . . . . . . . . . . 25 95 4.21. Misc. considerations . . . . . . . . . . . . . . . . . . 25 97 5. Document Status . . . . . . . . . . . . . . . . . . . . . . . 26 98 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 99 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 100 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 101 9. Research Group Information . . . . . . . . . . . . . . . . . 27 102 10. Informative References . . . . . . . . . . . . . . . . . . . 27 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 105 1. Introduction 107 This document outlines a set of human rights protocol considerations 108 for protocol developers. It provides questions engineers should ask 109 themselves when developing or improving protocols if they want to 110 understand how their decisions can potentially influence the exercise 111 of human rights on the Internet. It should be noted that the impact 112 of a protocol cannot solely be deduced from its design, but its usage 113 and implementation should also be studied to form a full protocol 114 human rights impact assessment. 116 The questions are based on the research performed by the Human Rights 117 Protocol Considerations (hrpc) research group which has been 118 documented before these considerations. The research establishes 119 that human rights relate to standards and protocols, and offers a 120 common vocabulary of technical concepts that influence human rights 121 and how these technical concepts can be combined to ensure that the 122 Internet remains an enabling environment for human rights. With 123 this, the contours of a model for developing human rights protocol 124 considerations has taken shape. 126 This document is an iteration of the guidelines that can be found in 127 [RFC8280]. The methods for conducting human rights reviews 128 (Section 3.2), and guidelines for human rights considerations 129 (Section 3.3) in this document are being tested for relevance, 130 accuracy, and validity. The understanding of what human rights are 131 is based on the Universal Declaration of Human Rights [UDHR] and 132 subsequent treaties that jointly form the body of international human 133 rights law [UNHR]. 135 This document does not provide a detailed taxonomy of the nature of 136 (potential) human rights violations, whether direct or indirect, 137 long-term or short-term, certain protocol choices might present. In 138 part because this is highly context-dependent, and in part, because 139 this document aims to provide a practical set of guidelines. 140 However, further research in this field would definitely benefit 141 developers and implementers. 143 This document is not an Internet Standards Track specification; it is 144 published for informational purposes. 146 This informational document has consensus for publication from the 147 Internet Research Task Force (IRTF) Human Right Protocol 148 Considerations Research Group. It has been reviewed, tried, and 149 tested by both by the research group as well as by researchers and 150 practitioners from outside the research group. The research group 151 acknowledges that the understanding of the impact of internet 152 protocols and architecture on society is a developing practice and is 153 a body of research that is still in development. 155 2. Human rights threats 157 Threats to the exercise of human rights on the Internet come in many 158 forms. Protocols and standards may harm or enable the right to 159 freedom of expression, right to freedom of information, right to non- 160 discrimination, right to equal protection, right to participate in 161 cultural life, arts and science, right to freedom of assembly and 162 association, right to privacy, and the right to security. An end- 163 user who is denied access to certain services or content may be 164 unable to disclose vital information about the malpractices of a 165 government or other authority. A person whose communications are 166 monitored may be prevented or dissuaded from exercising their right 167 to freedom of association or participate in political processes 168 [Penney]. In a worst-case scenario, protocols that leak information 169 can lead to physical danger. A realistic example to consider is when 170 individuals perceived as threats to the state are subjected to 171 torture, extra-judicial killing or detention on the basis of 172 information gathered by state agencies through the monitoring of 173 network traffic. 175 This document presents several examples of how threats to human 176 rights materialize on the Internet. This threat modeling is inspired 177 by [RFC6973] Privacy Considerations for Internet Protocols, which is 178 based on security threat analysis. This method is a work in progress 179 and by no means a perfect solution for assessing human rights risks 180 in Internet protocols and systems. Certain specific human rights 181 threats are indirectly considered in Internet protocols as part of 182 the security considerations [BCP72], but privacy considerations 183 [RFC6973] or reviews, let alone human rights impact assessments of 184 protocols are not standardized or implemented. 186 Many threats, enablers, and risks are linked to different rights. 187 This is not surprising if one takes into account that human rights 188 are interrelated, interdependent, and indivisible. Here however 189 we're not discussing all human rights because not all human rights 190 are relevant to ICTs in general and protocols and standards in 191 particular [Bless]: "The main source of the values of human rights is 192 the International Bill of Human Rights that is composed of the 193 Universal Declaration of Human Rights [UDHR] along with the 194 International Covenant on Civil and Political Rights [ICCPR] and the 195 International Covenant on Economic, Social and Cultural Rights 196 [ICESCR]. In the light of several cases of Internet censorship, the 197 Human Rights Council Resolution 20/8 was adopted in 2012, affirming 198 that "the same rights that people have offline must also be protected 199 online." [UNHRC2016] In 2015, the Charter of Human Rights and 200 Principles for the Internet [IRP] was developed and released. 201 According to these documents, some examples of human rights relevant 202 for ICT systems are human dignity (Art. 1 UDHR), non-discrimination 203 (Art. 2), rights to life, liberty and security (Art. 3), freedom of 204 opinion and expression (Art. 19), freedom of assembly and association 205 (Art. 20), rights to equal protection, legal remedy, fair trial, due 206 process, presumed innocent (Art. 7-11), appropriate social and 207 international order (Art. 28), participation in public affairs (Art. 208 21), participation in cultural life, protection of the moral and 209 material interests resulting from any scientific, literary or 210 artistic production of which [they are] the author (Art. 27), and 211 privacy (Art. 12)." A partial catalog of human rights related to 212 Information and Communications Technologies, including economic 213 rights, can be found in [Hill2014]. 215 This is by no means an attempt to exclude specific rights or 216 prioritize some rights over others. 218 3. Conducting human rights reviews 220 Ideally, protocol developers and collaborators should incorporate 221 human rights considerations into the design process itself (see 222 Guidelines for human rights considerations). This section provides 223 guidance on how to conduct a human rights review, i.e. gauge the 224 impact or potential impact of a protocol or standard on human rights. 226 Human rights reviews can take place at different stages of the 227 development process of an Internet-Draft. Generally speaking, it is 228 easier to influence the development of a technology at earlier stages 229 than at later stages. This does not mean that reviews at last-call 230 are not relevant, but they are less likely to result in significant 231 changes in the reviewed document. 233 Methods for analyzing technology for specific human rights impacts 234 are still quite nascent. Currently, five methods have been explored 235 by the Human Rights Review Team, often in conjunction with each 236 other: 238 3.1. Analyzing drafts based on guidelines for human rights 239 considerations model 241 This analysis of Internet-Drafts uses the model as described in 242 section 3.3. The outlined categories and questions can be used to 243 review an Internet-Draft. The advantage of this is that it provides 244 a known overview, and document authors can go back to this document 245 as well as [RFC8280] to understand the background and the context. 247 3.2. Analyzing drafts based on their perceived or speculated impact 249 When reviewing an Internet-Draft, specific human rights impacts can 250 become apparent by doing a close reading of the draft and seeking to 251 understand how it might affect networks or society. While less 252 structured than the straight use of the human rights considerations 253 model, this analysis may lead to new speculative understandings of 254 links between human rights and protocols. 256 3.3. Expert interviews 258 Interviews with document authors, active members of the Working 259 Group, or experts in the field can help explore the characteristics 260 of the protocol and its effects. There are two main advantages to 261 this approach: one the one hand, it allows the reviewer to gain a 262 deeper understanding of the (intended) workings of the protocol; on 263 the other hand, it also allows for the reviewer to start a discussion 264 with experts or even document authors, which can help the review gain 265 traction when it is published. 267 3.4. Interviews with impacted persons and communities 269 Protocols impact users of the Internet. Interviews can help the 270 reviewer understand how protocols affect the people that use the 271 protocols. Since human rights are best understood from the 272 perspective of the rights-holder, this approach will improve the 273 understanding of the real world effects of the technology. At the 274 same time, it can be hard to attribute specific changes to a 275 particular protocol, this is of course even harder when a protocol 276 has not been (widely) deployed. 278 3.5. Tracing impacts of implementations 280 The reality of deployed protocols can be at odds with the 281 expectations during the protocol design and development phase 282 [RFC8980]. When a specification already has associated running code, 283 the code can be analyzed either in an experimental setting or on the 284 Internet where its impact can be observed. In contrast to reviewing 285 the draft text, this approach can allow the reviewer to understand 286 how the specifications works in practice, and potentially what 287 unknown or unexpected effects the technology has. 289 4. Guidelines for human rights considerations 291 This section provides guidance for document authors in the form of a 292 questionnaire about protocols and how technical decisions can shape 293 the exercise of human rights. The questionnaire may be useful at any 294 point in the design process, particularly after the document authors 295 have developed a high-level protocol model as described in [RFC4101]. 296 These guidelines do not seek to replace any existing referenced 297 specifications, but rather contribute to them and look at the design 298 process from a human rights perspective. 300 Protocols and Internet Standards might benefit from a documented 301 discussion of potential human rights risks arising from potential 302 misapplications of the protocol or technology described in the RFC. 303 This might be coupled with an Applicability Statement for that RFC. 305 Note that the guidance provided in this section does not recommend 306 specific practices. The range of protocols developed in the IETF is 307 too broad to make recommendations about particular uses of data or 308 how human rights might be balanced against other design goals. 309 However, by carefully considering the answers to the following 310 questions, document authors should be able to produce a comprehensive 311 analysis that can serve as the basis for discussion on whether the 312 protocol adequately takes specific human rights threats into account. 313 This guidance is meant to help the thought process of a human rights 314 analysis; it does not provide specific directions for how to write a 315 human rights considerations section (following the example set in 316 [RFC6973]). 318 In considering these questions, authors will need to be aware of the 319 potential of technical advances or the passage of time to undermine 320 protections. In general, considerations of rights are likely to be 321 more effective if they are considered given a purpose and specific 322 use cases, rather than as abstract absolute goals. 324 Also note that while the section uses the word, 'protocol', the 325 principles identified in these questions may be applicable to other 326 types of solutions (extensions to existing protocols, architecture 327 for solutions to specific problems, etc.). 329 4.1. Connectivity 331 Question(s): Does your protocol add application-specific functions to 332 intermediary nodes? Could this functionality be added to end nodes 333 instead of intermediary nodes? 334 Is your protocol optimized for low bandwidth and high latency 335 connections? Could your protocol also be developed in a stateless 336 manner? 338 Explanation: The end-to-end principle [Saltzer] holds that certain 339 functions can and should be performed at 'ends' of the network. 340 [RFC1958] states "that in very general terms, the community believes 341 that the goal is connectivity [...] and the intelligence is end to 342 end rather than hidden in the network." Generally speaking, it is 343 easier to attain reliability of data transmissions with computation 344 at endpoints rather than at intermediary nodes. 346 Also considering the fact that network quality and conditions vary 347 across geography and time, it is also important to design protocols 348 such that they are reliable even on low bandwidth and high latency 349 connections. 351 Example: Encrypting connections, like done with HTTPS, can add a 352 significant network overhead and consequently make web resources less 353 accessible to those with low bandwidth and/or high latency 354 connections. [HTTPS-REL] Encrypting traffic is a net positive for 355 privacy and security, and thus protocol designers can acknowledge the 356 tradeoffs of connectivity made by such decisions. 358 Impacts: 360 * Right to freedom of expression 362 * Right to freedom of assembly and association 364 4.2. Reliability 366 Question(s): Is your protocol fault tolerant? Does it downgrade 367 gracefully, i.e. with mechanisms for fallback and/or notice? Can 368 your protocol resist malicious degradation attempts? Do you have a 369 documented way to announce degradation? Do you have measures in 370 place for recovery or partial healing from failure? Can your 371 protocol maintain dependability and performance in the face of 372 unanticipated changes or circumstances? 374 Explanation: Reliability and resiliency ensures that a protocol will 375 execute its function consistently and error resistant as described, 376 and function without unexpected result. Measures for reliability in 377 protocols assure users that their intended communication was 378 successfully executed. 380 A system that is reliable degrades gracefully and will have a 381 documented way to announce degradation. It also has mechanisms to 382 recover from failure gracefully, and if applicable, allow for partial 383 healing. 385 It is important here to draw a distinction between random degradation 386 and malicious degradation. Many current attacks against TLS, for 387 example, exploit TLS' ability to gracefully downgrade to non-secure 388 cipher suites - from a functional perspective, this is useful; from a 389 security perspective, this can be disastrous. As with 390 confidentiality, the growth of the Internet and fostering innovation 391 in services depends on users having confidence and trust [RFC3724] in 392 the network. For reliability, it is necessary that services notify 393 the users if a delivery fails. In the case of real-time systems in 394 addition to the reliable delivery the protocol needs to safeguard 395 timeliness. 397 Example: In the modern IP stack structure, a reliable transport layer 398 requires an indication that transport processing has successfully 399 completed, such as given by TCP's ACK message [RFC0793], and not 400 simply an indication from the IP layer that the packet arrived. 401 Similarly, an application layer protocol may require an application- 402 specific acknowledgment that contains, among other things, a status 403 code indicating the disposition of the request (See [RFC3724]). 405 Impacts: 407 * Right to freedom of expression 409 * Right to security 411 4.3. Content agnosticism 413 Question(s): If your protocol impacts packet handling, does it use 414 user data (packet data that is not included in the header)? Is it 415 making decisions based on the payload of the packet? Does your 416 protocol prioritize certain content or services over others in the 417 routing process? Is the protocol transparent about the 418 prioritization that is made (if any)? 420 Explanation: Content agnosticism refers to the notion that network 421 traffic is treated identically regardless of payload, with some 422 exceptions where it comes to effective traffic handling, for instance 423 where it comes to delay-tolerant or delay-sensitive packets, based on 424 the header. If there is any prioritization based on the content or 425 metadata of the protocol, the protocol should be transparent about 426 such information and reasons thereof. 428 Example: Content agnosticism prevents payload-based discrimination 429 against packets. This is important because changes to this principle 430 can lead to a two-tiered Internet, where certain packets are 431 prioritized over others on the basis of their content. Effectively 432 this would mean that although all users are entitled to receive their 433 packets at a certain speed, some users become more equal than others. 435 Impacts: 437 * Right to freedom of expression 439 * Right to non-discrimination 441 * Right to equal protection 443 4.4. Localization 445 Question(s): Does your protocol uphold the standards of 446 internationalization? Have you made any concrete steps towards 447 localizing your protocol for relevant audiences? 449 Explanation: Localization refers to the adaptation of a product, 450 application or document content to meet the language, cultural and 451 other requirements of a specific target market (a locale) 452 [W3Ci18nDef]. For our purposes, it can be described as the practice 453 of translating an implementation to make it functional in a specific 454 language or for users in a specific locale (see 455 Internationalization). 457 Example: The Internet is a global medium, but many of its protocols 458 and products are developed with a certain audience in mind, that 459 often share particular characteristics like knowing how to read and 460 write in ASCII and knowing English. This limits the ability of a 461 large part of the world's online population from using the Internet 462 in a way that is culturally and linguistically accessible. An 463 example of a protocol that has taken into account the view that 464 individuals like to have access to data in their native language can 465 be found in [RFC5646]. This protocol labels the information content 466 with an identifier for the language in which it is written. And this 467 allows information to be presented in more than one language. 469 Impacts: 471 * Right to non-discrimination 473 * Right to participate in cultural life, arts and science 475 * Right to freedom of expression 477 4.5. Internationalization 479 Question(s): Does your protocol or specification define text string 480 elements, in the payload or headers, that have to be understood or 481 entered by humans? Does your specification allow Unicode? If so, do 482 you accept texts in one charset (which must be UTF-8), or several 483 (which is dangerous for interoperability)? If character sets or 484 encodings other than UTF-8 are allowed, does your specification 485 mandate a proper tagging of the charset? Did you have a look at 486 [RFC6365]? 488 Explanation: Internationalization refers to the practice of making 489 protocols, standards, and implementations usable in different 490 languages and scripts (see Localization). In the IETF, 491 internationalization means to add or improve the handling of non- 492 ASCII text in a protocol. [RFC6365] A different perspective, more 493 appropriate to protocols that are designed for global use from the 494 beginning, is the definition used by W3C: 496 "Internationalization is the design and development of a 497 product, application or document content that enables easy 498 localization for target audiences that vary in culture, region, 499 or language." {{W3Ci18nDef}} 501 Many protocols that handle text only handle one charset (US-ASCII), 502 or leave the question of what coded character set and encoding are 503 used up to local guesswork (which leads, of course, to 504 interoperability problems). If multiple charsets are permitted, they 505 must be explicitly identified [RFC2277]. Adding non-ASCII text to a 506 protocol allows the protocol to handle more scripts, hopefully 507 representing users across the world. In today's world, that is 508 normally best accomplished by allowing Unicode encoded in UTF-8 only. 510 In the current IETF policy [RFC2277], internationalization is aimed 511 at user-facing strings, not protocol elements, such as the verbs used 512 by some text-based protocols. (Do note that some strings are both 513 content and protocol elements, such as identifiers.) Given the 514 IETF's mission to make the Internet a global network of networks, 515 [RFC3935] developers should ensure that protocols work with languages 516 apart from English and character sets apart from Latin characters. 517 It is therefore crucial that at the very least, the content carried 518 by the protocol can be in any script, and that all scripts are 519 treated equally. 521 Example: See localization 523 Impacts: 525 * Right to freedom of expression 527 * Right to political participation 529 * Right to participate in cultural life, arts and science 531 4.6. Open Standards 533 Question(s): Is your protocol fully documented in a way that it could 534 be easily implemented, improved, built upon and/or further developed? 535 Do you depend on proprietary code for the implementation, running or 536 further development of your protocol? Does your protocol favor a 537 particular proprietary specification over technically-equivalent 538 competing specification(s), for instance by making any incorporated 539 vendor specification "required" or "recommended" [RFC2026]? Do you 540 normatively reference another standard that is not available without 541 cost (and could you do without it)? Are you aware of any patents 542 that would prevent your standard from being fully implemented 543 [RFC8179] [RFC6701]? 545 Explanation: The Internet was able to be developed into the global 546 network of networks because of the existence of open, non-proprietary 547 standards [Zittrain]. They are crucial for enabling 548 interoperability. Yet, open standards are not explicitly defined 549 within the IETF. On the subject, [RFC2026] states: "Various national 550 and international standards bodies, such as ANSI, ISO, IEEE, and ITU- 551 T, develop a variety of protocol and service specifications that are 552 similar to Technical Specifications defined at the IETF. National 553 and international groups also publish "implementors' agreements" that 554 are analogous to Applicability Statements, capturing a body of 555 implementation-specific detail concerned with the practical 556 application of their standards. All of these are considered to be 557 "open external standards" for the purposes of the Internet Standards 558 Process." Similarly, [RFC3935] does not define open standards but 559 does emphasize the importance of an "open process", i.e. "any 560 interested person can participate in the work, know what is being 561 decided, and make his or her voice heard on the issue." 563 Open standards (and open source software) allow users to glean 564 information about how the tools they are using work, including the 565 tools' security and privacy properties. They additionally allow for 566 permissionless innovation, which is important to maintain the freedom 567 and ability to freely create and deploy new protocols on top of the 568 communications constructs that currently exist. It is at the heart 569 of the Internet as we know it, and to maintain its fundamentally open 570 nature, we need to be mindful of the need for developing open 571 standards. 573 All standards that need to be normatively implemented should be 574 freely available and with reasonable protection for patent 575 infringement claims, so it can also be implemented in open source or 576 free software. Patents have often held back open standardization or 577 been used against those deploying open standards, particularly in the 578 domain of cryptography [newegg]. An exemption of this is sometimes 579 made when a protocol is standardized that normatively relies on 580 specifications produced by others SDOs that are not freely available. 581 Patents in open standards or in normative references to other 582 standards should have a patent disclosure [notewell], royalty-free 583 licensing [patentpolicy], or some other form of fair, reasonable and 584 non-discriminatory terms. 586 Example: [RFC6108] describes a system for providing critical end-user 587 notifications to web browsers, which has been deployed by Comcast, an 588 Internet Service Provider (ISP). Such a notification system is being 589 used to provide near-immediate notifications to customers, such as to 590 warn them that their traffic exhibits patterns that are indicative of 591 malware or virus infection. There are other proprietary systems that 592 can perform such notifications, but those systems utilize Deep Packet 593 Inspection (DPI) technology. In contrast, that document describes a 594 system that does not rely upon DPI, and is instead based on open IETF 595 standards and open source applications. 597 Impacts: 599 * Right to freedom of expression 601 * Right to participate in cultural life, arts and science 603 4.7. Heterogeneity Support 605 Question(s): Does your protocol support heterogeneity by design? 606 Does your protocol allow for multiple types of hardware? Does your 607 protocol allow for multiple types of application protocols? Is your 608 protocol liberal in what it receives and handles? Will it remain 609 usable and open if the context changes? 610 Explanation: The Internet is characterized by heterogeneity on many 611 levels: devices and nodes, router scheduling algorithms and queue 612 management mechanisms, routing protocols, levels of multiplexing, 613 protocol versions and implementations, underlying link layers (e.g., 614 point-to-point, multi-access links, wireless, FDDI, etc.), in the 615 traffic mix and in the levels of congestion at different times and 616 places. Moreover, as the Internet is composed of autonomous 617 organizations and Internet service providers, each with their own 618 separate policy concerns, there is a large heterogeneity of 619 administrative domains and pricing structures. As a result, the 620 heterogeneity principle proposed in [RFC1958] needs to be supported 621 by design [FIArch]. 623 Heterogeneity support in protocols can thus enable a wide range of 624 devices and (by extension) users to participate on the network. 626 Example: Heterogeneity is inevitable and needs be supported by 627 design. Multiple types of hardware must be allowed for, e.g. 628 transmission speeds differing by at least 7 orders of magnitude, 629 various computer word lengths, and hosts ranging from memory-starved 630 microprocessors up to massively parallel supercomputers. Multiple 631 types of application protocols must be allowed for, ranging from the 632 simplest such as remote login up to the most complex such as commit 633 protocols for distributed databases. [RFC1958]. 635 Impacts: 637 * Right to freedom of expression 639 * Right to political participation 641 4.8. Integrity 643 Question(s): Does your protocol maintain, assure and/or verify the 644 accuracy of payload data? Does your protocol maintain and assure the 645 consistency of data? Does your protocol in any way allow for the 646 data to be (intentionally or unintentionally) altered? 648 Explanation: Integrity refers to the maintenance and assurance of the 649 accuracy and consistency of data to ensure it has not been 650 (intentionally or unintentionally) altered. 652 Example: Integrity verification of data is important to prevent 653 vulnerabilities and attacks from on-path attackers. These attacks 654 happen when a third party (often for malicious reasons) intercepts a 655 communication between two parties, inserting themselves in the middle 656 changing the content of the data. In practice this looks as follows: 658 Alice wants to communicate with Bob. Corinne forges and sends a 659 message to Bob, impersonating Alice. Bob cannot see the data from 660 Alice was altered by Corinne. Corinne intercepts and alters the 661 communication as it is sent between Alice and Bob. Corinne is able 662 to control the communication content. 664 Impacts: 666 * Right to freedom of expression 668 * Right to security 670 4.9. Authenticity 672 Question(s): Do you have sufficient measures to confirm the truth of 673 an attribute of a single piece of data or entity? Can the attributes 674 get garbled along the way (see security)? If relevant, have you 675 implemented IPsec, DNSsec, HTTPS and other Standard Security Best 676 Practices? 678 Explanation: Authenticity ensures that data does indeed come from the 679 source it claims to come from. This is important to prevent certain 680 attacks or unauthorized access and use of data. 682 At the same time, authentication should not be used as a way to 683 prevent heterogeneity support, as is often done for vendor lock-in or 684 digital rights management. 686 Example: Authentication of data is important to prevent 687 vulnerabilities, and attacks from on-path attackers. These attacks 688 happen when a third party (often for malicious reasons) intercepts a 689 communication between two parties, inserting themselves in the middle 690 and posing as both parties. In practice this looks as follows: 692 Alice wants to communicate with Bob. Alice sends data to Bob. 693 Corinne intercepts the data sent to Bob. Corinne reads (and 694 potentially alters) the message to Bob. Bob cannot see the data did 695 not come from Alice but from Corinne. 697 When there is proper authentication the scenario would be as follows: 699 Alice wants to communicate with Bob. Alice sends data to Bob. 700 Corinne intercepts the data sent to Bob. Corinne reads and alters 701 the message to Bob. Bob can see the data did not come from Alice. 703 Impacts: 705 * Right to privacy 706 * Right to freedom of expression 708 * Right to security 710 4.10. Confidentiality 712 Question(s): Does this protocol expose the transmitted data over the 713 wire? Does the protocol expose information related to identifiers or 714 data? If so, does it do so to each other protocol entity (i.e., 715 recipients, intermediaries, and enablers) [RFC6973]? What options 716 exist for protocol implementers to choose to limit the information 717 shared with each entity? What operational controls are available to 718 limit the information shared with each entity? 720 What controls or consent mechanisms does the protocol define or 721 require before personal data or identifiers are shared or exposed via 722 the protocol? If no such mechanisms or controls are specified, is it 723 expected that control and consent will be handled outside of the 724 protocol? 726 Does the protocol provide ways for initiators to share different 727 pieces of information with different recipients? If not, are there 728 mechanisms that exist outside of the protocol to provide initiators 729 with such control? 731 Does the protocol provide ways for initiators to limit the sharing or 732 express individuals' preferences to recipients or intermediaries with 733 regard to the collection, use, or disclosure of their personal data? 734 If not, are there mechanisms that exist outside of the protocol to 735 provide users with such control? Is it expected that users will have 736 relationships that govern the use of the information (contractual or 737 otherwise) with those who operate these intermediaries? Does the 738 protocol prefer encryption over clear text operation? 740 Explanation: Confidentiality refers to keeping your data secret from 741 unintended listeners [BCP72]. The growth of the Internet depends on 742 users having confidence that the network protects their personal data 743 [RFC1984]. The possibility of pervasive monitoring and surveillance 744 undermines users' trust, and can be mitigated by ensuring 745 confidentiality, i.e. passive attackers should gain little or no 746 information from observation or inference of protocol activity. 747 [RFC7258][RFC7624]. 749 Example: Protocols that do not encrypt their payload make the entire 750 content of the communication available to the idealized attacker 751 along their path. Following the advice in [RFC3365], most such 752 protocols have a secure variant that encrypts the payload for 753 confidentiality, and these secure variants are seeing ever-wider 754 deployment. A noteworthy exception is DNS [RFC1035], as DNSSEC 755 [RFC4033] does not have confidentiality as a requirement. This 756 implies that, in the absence of the use of more recent standards like 757 DNS over TLS [RFC7858] or DNS over HTTPS [RFC8484], all DNS queries 758 and answers generated by the activities of any protocol are available 759 to the attacker. When store-and-forward protocols are used (e.g., 760 SMTP [RFC5321]), intermediaries leave this data subject to 761 observation by an attacker that has compromised these intermediaries, 762 unless the data is encrypted end-to-end by the application-layer 763 protocol or the implementation uses an encrypted store for this data 764 [RFC7624]. 766 Impacts: 768 * Right to privacy 770 * Right to security 772 4.11. Security 774 Question(s): Did you have a look at Guidelines for Writing RFC Text 775 on Security Considerations [BCP72]? Have you found any attacks that 776 are somewhat related to your protocol/specification, yet considered 777 out of scope of your document? Would these attacks be pertinent to 778 the human rights enabling features of the Internet (as described 779 throughout this document)? 781 Explanation: Security is not a single monolithic property of a 782 protocol or system, but rather a series of related but somewhat 783 independent properties. Not all of these properties are required for 784 every application. Since communications are carried out by systems 785 and access to systems is through communications channels, security 786 goals obviously interlock, but they can also be independently 787 provided. [BCP72]. 789 Typically, any protocol operating on the internet can be the target 790 of passive attacks (when the attacker can access and read packets on 791 the network); active attacks (when an attacker is capable of writing 792 information to the network packets). [BCP72] 794 Example: See [BCP72]. 796 Impacts: 798 * Right to freedom of expression 800 * Right to freedom of assembly and association 801 * Right to non-discrimination 803 * Right to security 805 4.12. Privacy 807 Question(s): Did you have a look at the Guidelines in the Privacy 808 Considerations for Internet Protocols [RFC6973] section 7? Does your 809 protocol maintain the confidentiality of metadata? Could your 810 protocol counter traffic analysis? Does your protocol adhere to data 811 minimization principles? Does your document identify potentially 812 sensitive data logged by your protocol and/or for how long that needs 813 to be retained for technical reasons? 815 Explanation: Privacy refers to the right of an entity (normally a 816 person), acting on its own behalf, to determine the degree to which 817 it will interact with its environment, including the degree to which 818 the entity is willing to share its personal information with others. 819 [RFC4949]. If a protocol provides insufficient privacy protection it 820 may have a negative impact on freedom of expression as users self- 821 censor for fear of surveillance, or find themselves unable to express 822 themselves freely. 824 Example: See [RFC6973] 826 Impacts: 828 * Right to freedom of expression 830 * Right to non-discrimination 832 4.13. Pseudonymity 834 Question(s): Does the protocol collect personally derived data? Does 835 the protocol generate or process anything that can be, or be tightly 836 correlated with, personally identifiable information? Does the 837 protocol utilize data that is personally-derived, i.e. derived from 838 the interaction of a single person, or their device or address? If 839 yes, can the protocol be implemented in a way that does not rely on 840 personally identifiable information? If not, does the specification 841 describe how any such data be handled? Have you considered the 842 Privacy Considerations for Internet Protocols [RFC6973], especially 843 section 6.1.2? 845 Explanation: Pseudonymity means using a pseudonym instead of one's 846 "real" name. There are many reasons for users to use pseudonyms, for 847 instance to: hide their gender, protect themselves against 848 harassment, protect their families' privacy, frankly discuss 849 sexuality, or develop an artistic or journalistic persona without 850 repercussions from an employer, (potential) customers, or social 851 surrounding. [geekfeminism] The difference between anonymity and 852 pseudonymity is that a pseudonym often is persistent. "Pseudonymity 853 is strengthened when less personal data can be linked to the 854 pseudonym; when the same pseudonym is used less often and across 855 fewer contexts; and when independently chosen pseudonyms are more 856 frequently used for new actions (making them, from an observer's or 857 attacker's perspective, unlinkable)." [RFC6973] 859 Pseudonymity - the ability to use a persistent identifier not linked 860 to one's offline identity - is an important feature for many end- 861 users, as it allows them different degrees of disguised identity and 862 privacy online. This can allow an enabling environment for users to 863 exercise other rights, including freedom of expression and political 864 participation, without fear or direct identification or 865 discrimination. 867 Example: Generally, pseudonymous identifiers cannot be simply reverse 868 engineered. Some early approaches took approaches such as simple 869 hashing of IP addresses, but these could then be simply reversed by 870 generating a hash for each potential IP address and comparing it to 871 the pseudonym. 873 Example: There are also efforts for application layer protocols, like 874 Oblivious DNS Over HTTPS, [draft-pauly-dprive-oblivious-doh] that can 875 separate identifiers from requests. 877 Impacts: 879 * Right to non-discrimination 881 * Right to freedom of expression 883 * Right to political participation 885 * Right to freedom of assembly and association 887 4.14. Anonymity 889 Question(s): Does your protocol make use of persistent identifiers? 890 Can it be done without them? Did you have a look at the Privacy 891 Considerations for Internet Protocols [RFC6973], especially section 892 6.1.1 of that document? 894 Explanation: Anonymity refers to the condition of an identity being 895 unknown or concealed [RFC4949]. Even though full anonymity is hard 896 to achieve, it is a non-binary concept. Making pervasive monitoring 897 and tracking harder is important for many users as well as for the 898 IETF [RFC7258]. Achieving a higher level of anonymity is an 899 important feature for many end-users, as it allows them different 900 degrees of privacy online. Anonymity is an inherent part of the 901 right to freedom of opinion and expression and the right to privacy. 902 Avoid adding identifiers, options or configurations that create or 903 might lead to patterns or regularities that are not explicitly 904 required by the protocol. 906 If your protocol collects data and seeks to distribute it to more 907 etntities than the originally-intended recipients (see [RFC6235] as 908 an example), you should anonymize the data, but keep in mind that 909 "anonymizing" data is notoriously hard. For example, just dropping 910 the last byte of an IP address does not "anonymize" data. 912 If your protocol allows for identity management, there should be a 913 clear barrier between the identities to ensure that they cannot 914 (easily) be associated with each other. 916 A protocol that uses data that could help identify a sender (items of 917 interest) should be protected from third parties. For instance, if 918 one wants to hide the source/destination IP addresses of a packet, 919 the use of IPsec in tunneling mode (e.g., inside a virtual private 920 network) can be helpful to protect from third parties likely to 921 eavesdrop packets exchanged between the tunnel endpoints. 923 Example: An example is DHCP where sending a persistent identifier as 924 the client name was not mandatory but, in practice, done by many 925 implementations, before [RFC7844]. 927 Impacts: 929 * Right to non-discrimination 931 * Right to political participation 933 * Right to freedom of assembly and association 935 * Right to security 937 4.15. Censorship resistance 939 Question(s): Can your protocol contribute to filtering? Could be 940 implemented to censor data or services? Could it be designed to 941 ensure this doesn't happen? Does your protocol make it apparent or 942 transparent when access to a resource is restricted and reasons 943 therefor? Does your protocol introduce new identifiers or reuse 944 existing identifiers (e.g. MAC addresses) that might be associated 945 with persons or content? 947 Explanation: Governments and service providers block or filter 948 content or traffic, often without the knowledge of end-users. 949 [RFC7754] See [draft-irtf-pearg-censorship] for a survey of 950 censorship techniques employed across the world, which lays out 951 protocol properties that have been exploited to censor access to 952 information. Censorship resistance refers to the methods and 953 measures to prevent Internet censorship. 955 Example: Identifiers of content exposed within a protocol might be 956 used to facilitate censorship, as in the case of Application Layer 957 based censorship, which affects protocols like HTTP. In HTTP, denial 958 or restriction of access can be made apparent by the use of status 959 code 451, which allows server operators to operate with greater 960 transparency in circumstances where issues of law or public policy 961 affect their operation [RFC7725]. 963 If a protocol potentially enables censorship, protocol designers 964 should strive towards creating error codes that capture different 965 scenarios (blocked due to administrative policy, unavailable because 966 of legal requirements, etc.) to minimize ambiguity for end-users. 968 In the development of the IPv6 protocol, it was discussed to embed a 969 Media Access Control (MAC) address into unique IP addresses. This 970 would make it possible for 'eavesdroppers and other information 971 collectors to identify when different addresses used in different 972 transactions actually correspond to the same node. This is why 973 standardisation efforts like Privacy Extensions for Stateless Address 974 Autoconfiguration in IPv6 [RFC4941] and MAC address randomization 975 [draft-zuniga-mac-address-randomization] have been pursued. 977 Impacts: 979 * Right to freedom of expression 981 * Right to political participation 983 * Right to participate in cultural life, arts, and science 985 * Right to freedom of assembly and association 987 4.16. Outcome Transparency 989 Question(s): Are the effects of your protocol fully and easily 990 comprehensible, including with respect to unintended consequences of 991 protocol choices? 992 Explanation: Certain technical choices may have unintended 993 consequences. 995 Example: Lack of authenticity may lead to lack of integrity and 996 negative externalities, of which spam is an example. Lack of data 997 that could be used for billing and accounting can lead to so-called 998 "free" arrangements which obscure the actual costs and distribution 999 of the costs, for example the barter arrangements that are commonly 1000 used for Internet interconnection; and the commercial exploitation of 1001 personal data for targeted advertising which is the most common 1002 funding model for the so-called "free" services such as search 1003 engines and social networks. Other unexpected outcomes might not be 1004 technical, but rather architectural, social or economical. 1006 Impacts: 1008 * Right to freedom of expression 1010 * Right to privacy 1012 * Right to freedom of assembly and association 1014 * Right to access to information 1016 4.17. Adaptability 1018 Question(s): Is your protocol written in such a way that it would be 1019 easy for other protocols to be developed on top of it, or to interact 1020 with it? Does your protocol impact permissionless innovation? (See 1021 Open Standards) 1023 Explanation: Adaptability is closely interrelated with permissionless 1024 innovation: both maintain the freedom and ability to freely create 1025 and deploy new protocols on top of the communications constructs that 1026 currently exist. It is at the heart of the Internet as we know it, 1027 and to maintain its fundamentally open nature, we need to be mindful 1028 of the impact of protocols on maintaining or reducing permissionless 1029 innovation to ensure the Internet can continue to develop. 1031 Adaptability and permissionless innovation can be used to shape 1032 information networks as preferenced by groups of users. Furthermore, 1033 a precondition of adaptability is the ability of the people who can 1034 adapt the network to be able to know and understand the network. 1035 This is why adaptability and permissionless innovation are inherently 1036 connected to the right to education and the right to science as well 1037 as the right to freedom of assembly and association as well as the 1038 right to freedom of expression. Since it allows the users of the 1039 network to determine how the assemble, collaborate, and express 1040 themselves. 1042 Example: WebRTC generates audio and/or video data. In order to 1043 ensure that WebRTC can be used in different locations by different 1044 parties, it is important that standard Javascript APIs are developed 1045 to support applications from different voice service providers. 1046 Multiple parties will have similar capabilities, in order to ensure 1047 that all parties can build upon existing standards these need to be 1048 adaptable, and allow for permissionless innovation. 1050 Impacts: 1052 * Right to education 1054 * Right to science 1056 * Right to freedom of expression 1058 * Right to freedom of assembly and association 1060 4.18. Accessibility 1062 Question(s): Is your protocol designed to provide an enabling 1063 environment for all? Have you looked at the W3C Web Accessibility 1064 Initiative for examples and guidance? 1066 Explanation: Sometimes in the design of protocols, websites, web 1067 technologies, or web tools, barriers are created that exclude people 1068 from using the Web. The Internet should be designed to work for all 1069 people, whatever their hardware, software, language, culture, 1070 location, or physical or mental ability. When the Internet 1071 technologies meet this goal, it will be accessible to people with a 1072 diverse range of hearing, movement, sight, and cognitive ability. 1073 [W3CAccessibility] 1075 Example: The HTML protocol as defined in [HTML5] specifically 1076 requires that every image must have an alt attribute (with a few 1077 exceptions) to ensure images are accessible for people that cannot 1078 themselves decipher non-text content in web pages. 1080 Another example is the works that is done in the AVT and AVTCORE 1081 working groups in the IETF that enable text conversation in 1082 multimedia, text telephony, wireless multimedia and video 1083 communications for sign language and lip-reading (ie. [RFC9071]). 1085 Impacts: 1087 * Right to non-discrimination 1089 * Right to freedom of assembly and association 1091 * Right to education 1093 * Right to political participation 1095 4.19. Decentralization 1097 Question(s): Can your protocol be implemented without a single point 1098 of control? If applicable, can your protocol be deployed in a 1099 federated manner? Does your protocol create additional centralized 1100 points of control? 1102 Explanation: Decentralization is one of the central technical 1103 concepts of the architecture of the Internet, and is embraced as such 1104 by the IETF [RFC3935]. It refers to the absence or minimization of 1105 centralized points of control, a feature that is assumed to make it 1106 easy for new users to join and new uses to unfold [Brown]. It also 1107 reduces issues surrounding single points of failure, and distributes 1108 the network such that it continues to function even if one or several 1109 nodes are disabled. With the commercialization of the Internet in 1110 the early 1990s, there has been a slow move away from 1111 decentralization, to the detriment of the technical benefits of 1112 having a decentralized Internet. For a more detailed discussion of 1113 this topic, please see [arkkoetal]. 1115 Example: The bits traveling the Internet are increasingly susceptible 1116 to monitoring and censorship, from both governments and Internet 1117 service providers, as well as third (malicious) parties. The ability 1118 to monitor and censor is further enabled by the increased 1119 centralization of the network that creates central infrastructure 1120 points that can be tapped into. The creation of peer-to-peer 1121 networks and the development of voice-over-IP protocols using peer- 1122 to-peer technology in combination with distributed hash table (DHT) 1123 for scalability are examples of how protocols can preserve 1124 decentralization [Pouwelse]. 1126 Impacts: 1128 * Right to freedom of expression 1130 * Right to freedom of assembly and association 1132 4.20. Remedy 1134 Question(s): Can your protocol facilitate a negatively impacted 1135 party's right to remedy without disproportionately impacting other 1136 parties' human rights, especially their right to privacy? 1138 Explanation: Providing access to remedy by states and corporations is 1139 a part of the UN Guiding Principles on Business and Human Rights 1140 [UNGP]. Access to remedy may help victims of human rights violations 1141 in seeking justice, or allow law enforcement agencies to identify a 1142 possible violator. However, mechanisms in protocols that try to 1143 enable 'attribution' to individuals will impede the exercise of the 1144 right to privacy. The former Special Rapporteur for Freedom of 1145 Expression has also argued that anonymity is an inherent part of 1146 freedom of expression [Kaye]. Considering the potential adverse 1147 impact of attribution on the right to privacy and freedom of 1148 expression, enabling attribution on an individual level is most 1149 likely not consistent with human rights. 1151 Example: Adding personal identifiable information to data streams 1152 might help in identifying a violator of human rights and provide 1153 access to remedy, but this would disproportionally affect all users 1154 right to privacy, anonymous expression, and association. 1156 Impacts: 1158 * Right to remedy 1160 * Right to security 1162 * Right to privacy 1164 4.21. Misc. considerations 1166 Question(s): Have you considered potential negative consequences 1167 (individual or societal) that your protocol or document might have? 1169 Explanation: Publication of a particular RFC under a certain status 1170 has consequences. Publication as an Internet Standard as part of the 1171 Standards Track may signal to implementers that the specification has 1172 a certain level of maturity, operational experience, and consensus. 1173 Similarly, publication of a specification an experimental document as 1174 part of the non-standards track would signal to the community that 1175 the document "may be intended for eventual standardization but [may] 1176 not yet [be] ready" for wide deployment. The extent of the 1177 deployment, and consequently its overall impact on end-users, may 1178 depend on the document status presented in the RFC. See [BCP9] and 1179 updates to it for a fuller explanation. 1181 5. Document Status 1183 This RG document is currently documenting best practices and 1184 guidelines for human rights reviews of network protocols, 1185 architectures and other Internet-Drafts and RFCs. 1187 6. Acknowledgements 1189 Thanks to: 1191 * Corinne Cath-Speth for work on [RFC8280]. 1193 * Theresa Engelhard, Joe Hall, Avri Doria, Joey Salazar, Corinne 1194 Cath-Speth, Farzaneh Badii, Sandra Braman, Colin Perkins, John 1195 Curran, Eliot Lear, Mallory Knodel, and the hrpc list for reviews 1196 and suggestions. 1198 * Individuals who conducted human rights reviews for their work and 1199 feedback: Amelia Andersdotter, Beatrice Martini, Karan Saini and 1200 Shivan Kaul Sahib. 1202 7. Security Considerations 1204 Article three of the Universal Declaration of Human Rights reads: 1205 "Everyone has the right to life, liberty and security of person.". 1206 This article underlines the importance of security and its 1207 interrelation with human life and liberty, but since human rights are 1208 indivisible, interrelated and interdependent, security is also 1209 closely linked to other human rights and freedoms. This document 1210 seeks to strengthen human rights, freedoms, and security by relating 1211 and translating these concepts to concepts and practices as they are 1212 used in Internet protocol and architecture development. The aim of 1213 this is to secure human right and thereby improve the susainability, 1214 usability, and effectiveness of the network. The document seeks to 1215 achieve this by providing guidelines as done in section three of this 1216 document. 1218 8. IANA Considerations 1220 This document has no actions for IANA. 1222 9. Research Group Information 1224 The discussion list for the IRTF Human Rights Protocol Considerations 1225 Research Group is located at the e-mail address hrpc@ietf.org 1226 (mailto:hrpc@ietf.org). Information on the group and information on 1227 how to subscribe to the list is at 1228 https://www.irtf.org/mailman/listinfo/hrpc 1229 (https://www.irtf.org/mailman/listinfo/hrpc) 1231 Archives of the list can be found at: https://www.irtf.org/mail- 1232 archive/web/hrpc/current/index.html (https://www.irtf.org/mail- 1233 archive/web/hrpc/current/index.html) 1235 10. Informative References 1237 [arkkoetal] 1238 Arkko, J., Trammell, B., Notthingham, M., Huitema, C., 1239 Thomson, M., Tantsure, J., and N. ten Oever, 1240 "Considerations on Internet Consolidation and the Internet 1241 Architecture", 2019, 1242 . 1245 [BCP72] IETF, "Guidelines for Writing RFC Text on Security 1246 Considerations", 2003, 1247 . 1249 [BCP9] Bradner, S. and IETF, "The Internet Standards Process -- 1250 Revision 3", 1996, 1251 . 1253 [Bless] Bless, R. and C. Orwat, "Values and Networks", 2015. 1255 [Brown] Brown, I. and M. Ziewitz, "A Prehistory of Internet 1256 Governance", Research Handbook on Governance of the 1257 Internet. Cheltenham, Edward Elgar. , 2013. 1259 [draft-irtf-pearg-censorship] 1260 Hall, J., Aaron, M., Adams, S., Jones, B., and N. 1261 Feamster, "A Survey of Worldwide Censorship Techniques", 1262 2020, 1263 . 1265 [draft-pauly-dprive-oblivious-doh] 1266 Kinnear, E., McManus, P., Pauly, T., Verma, T., and C.A. 1267 Wood, "Oblivious DNS Over HTTPS", 2022, 1268 . 1271 [draft-zuniga-mac-address-randomization] 1272 Zuniga, JC., Bernardos, CJ., and A. Andersdotter, "MAC 1273 address randomization", 2020, 1274 . 1276 [FIArch] "Future Internet Design Principles", January 2012, 1277 . 1280 [geekfeminism] 1281 Geek Feminism Wiki, "Pseudonymity", 2015, 1282 . 1284 [Hill2014] Hill, R., "Partial Catalog of Human Rights Related to ICT 1285 Activities", 2014, 1286 . 1288 [HTML5] W3C, "HTML5", 2014, . 1290 [HTTPS-REL] 1291 Meyer, E., "Securing Web Sites Made Them Less Accessible", 1292 2018, . 1295 [ICCPR] United Nations General Assembly, "International Covenant 1296 on Civil and Political Rights", 1976, 1297 . 1300 [ICESCR] United Nations General Assembly, "International Covenant 1301 on Economic, Social and Cultural Rights", 1966, 1302 . 1305 [IRP] Internet Rights and Principles Dynamic Coalition, "10 1306 Internet Rights & Principles", 2014, 1307 . 1311 [Kaye] Kaye, D., "The use of encryption and anonymity in digital 1312 communications", 2015, 1313 . 1316 [newegg] Mullin, J., "Newegg on trial: Mystery company TQP rewrites 1317 the history of encryption", 2013, . 1321 [notewell] IETF, "Note Well", 2015, 1322 . 1324 [patentpolicy] 1325 W3C, "W3C Patent Policy", 2004, 1326 . 1328 [Penney] Penney, J., "Chilling Effects: Online Surveillance and 1329 Wikipedia Use", 2016, . 1332 [Pouwelse] Pouwelse, Ed, J., "Media without censorship", 2012, 1333 . 1336 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1337 RFC 793, DOI 10.17487/RFC0793, September 1981, 1338 . 1340 [RFC1035] Mockapetris, P., "Domain names - implementation and 1341 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1342 November 1987, . 1344 [RFC1958] Carpenter, B., Ed., "Architectural Principles of the 1345 Internet", RFC 1958, DOI 10.17487/RFC1958, June 1996, 1346 . 1348 [RFC1984] IAB and IESG, "IAB and IESG Statement on Cryptographic 1349 Technology and the Internet", BCP 200, RFC 1984, 1350 DOI 10.17487/RFC1984, August 1996, 1351 . 1353 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 1354 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, 1355 . 1357 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 1358 Languages", BCP 18, RFC 2277, DOI 10.17487/RFC2277, 1359 January 1998, . 1361 [RFC3365] Schiller, J., "Strong Security Requirements for Internet 1362 Engineering Task Force Standard Protocols", BCP 61, 1363 RFC 3365, DOI 10.17487/RFC3365, August 2002, 1364 . 1366 [RFC3724] Kempf, J., Ed., Austein, R., Ed., and IAB, "The Rise of 1367 the Middle and the Future of End-to-End: Reflections on 1368 the Evolution of the Internet Architecture", RFC 3724, 1369 DOI 10.17487/RFC3724, March 2004, 1370 . 1372 [RFC3935] Alvestrand, H., "A Mission Statement for the IETF", 1373 BCP 95, RFC 3935, DOI 10.17487/RFC3935, October 2004, 1374 . 1376 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1377 Rose, "DNS Security Introduction and Requirements", 1378 RFC 4033, DOI 10.17487/RFC4033, March 2005, 1379 . 1381 [RFC4101] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101, 1382 DOI 10.17487/RFC4101, June 2005, 1383 . 1385 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1386 Extensions for Stateless Address Autoconfiguration in 1387 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 1388 . 1390 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1391 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 1392 . 1394 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 1395 DOI 10.17487/RFC5321, October 2008, 1396 . 1398 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying 1399 Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, 1400 September 2009, . 1402 [RFC6108] Chung, C., Kasyanov, A., Livingood, J., Mody, N., and B. 1403 Van Lieu, "Comcast's Web Notification System Design", 1404 RFC 6108, DOI 10.17487/RFC6108, February 2011, 1405 . 1407 [RFC6235] Boschi, E. and B. Trammell, "IP Flow Anonymization 1408 Support", RFC 6235, DOI 10.17487/RFC6235, May 2011, 1409 . 1411 [RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in 1412 Internationalization in the IETF", BCP 166, RFC 6365, 1413 DOI 10.17487/RFC6365, September 2011, 1414 . 1416 [RFC6701] Farrel, A. and P. Resnick, "Sanctions Available for 1417 Application to Violators of IETF IPR Policy", RFC 6701, 1418 DOI 10.17487/RFC6701, August 2012, 1419 . 1421 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 1422 Morris, J., Hansen, M., and R. Smith, "Privacy 1423 Considerations for Internet Protocols", RFC 6973, 1424 DOI 10.17487/RFC6973, July 2013, 1425 . 1427 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1428 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 1429 2014, . 1431 [RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., 1432 Trammell, B., Huitema, C., and D. Borkmann, 1433 "Confidentiality in the Face of Pervasive Surveillance: A 1434 Threat Model and Problem Statement", RFC 7624, 1435 DOI 10.17487/RFC7624, August 2015, 1436 . 1438 [RFC7725] Bray, T., "An HTTP Status Code to Report Legal Obstacles", 1439 RFC 7725, DOI 10.17487/RFC7725, February 2016, 1440 . 1442 [RFC7754] Barnes, R., Cooper, A., Kolkman, O., Thaler, D., and E. 1443 Nordmark, "Technical Considerations for Internet Service 1444 Blocking and Filtering", RFC 7754, DOI 10.17487/RFC7754, 1445 March 2016, . 1447 [RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity 1448 Profiles for DHCP Clients", RFC 7844, 1449 DOI 10.17487/RFC7844, May 2016, 1450 . 1452 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 1453 and P. Hoffman, "Specification for DNS over Transport 1454 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 1455 2016, . 1457 [RFC8179] Bradner, S. and J. Contreras, "Intellectual Property 1458 Rights in IETF Technology", BCP 79, RFC 8179, 1459 DOI 10.17487/RFC8179, May 2017, 1460 . 1462 [RFC8280] ten Oever, N. and C. Cath, "Research into Human Rights 1463 Protocol Considerations", RFC 8280, DOI 10.17487/RFC8280, 1464 October 2017, . 1466 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 1467 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 1468 . 1470 [RFC8980] Arkko, J. and T. Hardie, "Report from the IAB Workshop on 1471 Design Expectations vs. Deployment Reality in Protocol 1472 Development", RFC 8980, DOI 10.17487/RFC8980, February 1473 2021, . 1475 [RFC9071] Hellström, G., "RTP-Mixer Formatting of Multiparty Real- 1476 Time Text", RFC 9071, DOI 10.17487/RFC9071, July 2021, 1477 . 1479 [Saltzer] Saltzer, J.H., Reed, D.P., and D.D. Clark, "End-to-End 1480 Arguments in System Design", ACM TOCS, Vol 2, Number 4, 1481 November 1984, pp 277-288. , 1984. 1483 [UDHR] United Nations General Assembly, "The Universal 1484 Declaration of Human Rights", 1948, 1485 . 1487 [UNGP] United Nations, "United Nations Guiding Principles on 1488 Business and Human Rights", 2011, 1489 . 1492 [UNHR] United Nations, "The Core International Human Rights 1493 Instruments and their monitoring bodies", 2011, 1494 . 1497 [UNHRC2016] 1498 United Nations Human Rights Council, "UN Human Rights 1499 Council Resolution "The promotion, protection and 1500 enjoyment of human rights on the Internet" (A/HRC/32/ 1501 L.20)", 2016, . 1505 [W3CAccessibility] 1506 W3C, "Accessibility", 2015, 1507 . 1509 [W3Ci18nDef] 1510 W3C, "Localization vs. Internationalization", 2010, 1511 . 1513 [Zittrain] Zittrain, J., "The Future of the Internet - And How to 1514 Stop It", Yale University Press , 2008, 1515 . 1518 Authors' Addresses 1520 Gurshabad Grover 1521 Centre for Internet and Society 1522 Email: gurshabad@cis-india.org 1524 Niels ten Oever 1525 University of Amsterdam 1526 Email: mail@nielstenoever.net