idnits 2.17.1
draft-irtf-hrpc-guidelines-10.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 (15 September 2021) is 952 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
-- Obsolete informational reference (is this intentional?): RFC 793
(Obsoleted by RFC 9293)
-- 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 (==), 5 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: 19 March 2022 15 September 2021
8 Guidelines for Human Rights Protocol and Architecture Considerations
9 draft-irtf-hrpc-guidelines-10
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 19 March 2022.
48 Copyright Notice
50 Copyright (c) 2021 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 Simplified BSD License text
59 as described in Section 4.e of the Trust Legal Provisions and are
60 provided without warranty as described in the Simplified BSD License.
62 Table of Contents
64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
65 2. Human rights threats . . . . . . . . . . . . . . . . . . . . 4
66 3. Guidelines for developing human rights protocol
67 considerations . . . . . . . . . . . . . . . . . . . . . 5
68 3.1. Conducting human rights reviews . . . . . . . . . . . . . 5
69 3.1.1. Analyzing drafts based on guidelines for human rights
70 considerations model . . . . . . . . . . . . . . . . 5
71 3.1.2. Analyzing drafts based on their perceived or speculated
72 impact . . . . . . . . . . . . . . . . . . . . . . . 5
73 3.1.3. Expert interviews . . . . . . . . . . . . . . . . . . 6
74 3.1.4. Interviews with impacted persons and communities . . 6
75 3.1.5. Tracing impacts of implementations . . . . . . . . . 6
76 3.2. Guidelines for human rights considerations . . . . . . . 6
77 3.2.1. Connectivity . . . . . . . . . . . . . . . . . . . . 7
78 3.2.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . 8
79 3.2.3. Content agnosticism . . . . . . . . . . . . . . . . . 8
80 3.2.4. Security . . . . . . . . . . . . . . . . . . . . . . 9
81 3.2.5. Internationalization . . . . . . . . . . . . . . . . 10
82 3.2.6. Censorship resistance . . . . . . . . . . . . . . . . 11
83 3.2.7. Open Standards . . . . . . . . . . . . . . . . . . . 12
84 3.2.8. Heterogeneity Support . . . . . . . . . . . . . . . . 14
85 3.2.9. Pseudonymity . . . . . . . . . . . . . . . . . . . . 15
86 3.2.10. Anonymity . . . . . . . . . . . . . . . . . . . . . . 16
87 3.2.11. Accessibility . . . . . . . . . . . . . . . . . . . . 17
88 3.2.12. Localization . . . . . . . . . . . . . . . . . . . . 17
89 3.2.13. Decentralization . . . . . . . . . . . . . . . . . . 18
90 3.2.14. Reliability . . . . . . . . . . . . . . . . . . . . . 19
91 3.2.15. Confidentiality . . . . . . . . . . . . . . . . . . . 20
92 3.2.16. Integrity . . . . . . . . . . . . . . . . . . . . . . 21
93 3.2.17. Authenticity . . . . . . . . . . . . . . . . . . . . 22
94 3.2.18. Adaptability . . . . . . . . . . . . . . . . . . . . 23
95 3.2.19. Outcome Transparency . . . . . . . . . . . . . . . . 23
96 3.2.20. Remedy . . . . . . . . . . . . . . . . . . . . . . . 24
97 3.2.21. Misc. considerations . . . . . . . . . . . . . . . . 25
98 4. Document Status . . . . . . . . . . . . . . . . . . . . . . . 25
99 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
100 6. Security Considerations . . . . . . . . . . . . . . . . . . . 25
101 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
102 8. Research Group Information . . . . . . . . . . . . . . . . . 26
103 9. Informative References . . . . . . . . . . . . . . . . . . . 26
104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
106 1. Introduction
108 This document outlines a set of human rights protocol considerations
109 for protocol developers. It provides questions engineers should ask
110 themselves when developing or improving protocols if they want to
111 understand how their decisions can potentially influence the exercise
112 of human rights on the Internet. It should be noted that the impact
113 of a protocol cannot solely be deduced from its design, but its usage
114 and implementation should also be studied to form a full protocol
115 human rights impact assessment.
117 The questions are based on the research performed by the Human Rights
118 Protocol Considerations (hrpc) research group which has been
119 documented before these considerations. The research establishes
120 that human rights relate to standards and protocols, and offers a
121 common vocabulary of technical concepts that influence human rights
122 and how these technical concepts can be combined to ensure that the
123 Internet remains an enabling environment for human rights. With
124 this, the contours of a model for developing human rights protocol
125 considerations has taken shape.
127 This document is an iteration of the guidelines that can be found in
128 [RFC8280]. The methods for conducting human rights reviews
129 (Section 3.2), and guidelines for human rights considerations
130 (Section 3.3) in this document are being tested for relevance,
131 accuracy, and validity. The understanding of what human rights are
132 is based on the Universal Declaration of Human Rights and subsequent
133 treaties that jointly form the body of international human rights
134 law.
136 This document does not provide a detailed taxonomy of the nature of
137 (potential) human rights violations, whether direct or indirect,
138 long-term or short-term, certain protocol choices might present. In
139 part because this is highly context-dependent, and in part, because
140 this document aims to provide a practical set of guidelines.
141 However, further research in this field would definitely benefit
142 developers and implementers.
144 2. Human rights threats
146 Threats to the exercise of human rights on the Internet come in many
147 forms. Protocols and standards may harm or enable the right to
148 freedom of expression, right to freedom of information, right to non-
149 discrimination, right to equal protection, right to participate in
150 cultural life, arts and science, right to freedom of assembly and
151 association, right to privacy, and the right to security. An end-
152 user who is denied access to certain services or content may be
153 unable to disclose vital information about the malpractices of a
154 government or other authority. A person whose communications are
155 monitored may be prevented or dissuaded from exercising their right
156 to freedom of association or participate in political processes
157 [Penney]. In a worst-case scenario, protocols that leak information
158 can lead to physical danger. A realistic example to consider is when
159 individuals perceived as threats to the state are subjected to
160 torture, extra-judicial killing or detention on the basis of
161 information gathered by state agencies through the monitoring of
162 network traffic.
164 This document presents several examples of how threats to human
165 rights materialize on the Internet. This threat modeling is inspired
166 by [RFC6973] Privacy Considerations for Internet Protocols, which is
167 based on security threat analysis. This method is a work in progress
168 and by no means a perfect solution for assessing human rights risks
169 in Internet protocols and systems. Certain specific human rights
170 threats are indirectly considered in Internet protocols as part of
171 the security considerations [BCP72], but privacy considerations
172 [RFC6973] or reviews, let alone human rights impact assessments of
173 protocols are not standardized or implemented.
175 Many threats, enablers, and risks are linked to different rights.
176 This is not surprising if one takes into account that human rights
177 are interrelated, interdependent, and indivisible. Here however
178 we're not discussing all human rights because not all human rights
179 are relevant to ICTs in general and protocols and standards in
180 particular [Bless]: "The main source of the values of human rights is
181 the International Bill of Human Rights that is composed of the
182 Universal Declaration of Human Rights [UDHR] along with the
183 International Covenant on Civil and Political Rights [ICCPR] and the
184 International Covenant on Economic, Social and Cultural Rights
185 [ICESCR]. In the light of several cases of Internet censorship, the
186 Human Rights Council Resolution 20/8 was adopted in 2012, affirming
187 that "the same rights that people have offline must also be protected
188 online." [UNHRC2016] In 2015, the Charter of Human Rights and
189 Principles for the Internet [IRP] was developed and released.
190 According to these documents, some examples of human rights relevant
191 for ICT systems are human dignity (Art. 1 UDHR), non-discrimination
192 (Art. 2), rights to life, liberty and security (Art. 3), freedom of
193 opinion and expression (Art. 19), freedom of assembly and association
194 (Art. 20), rights to equal protection, legal remedy, fair trial, due
195 process, presumed innocent (Art. 7-11), appropriate social and
196 international order (Art. 28), participation in public affairs (Art.
197 21), participation in cultural life, protection of the moral and
198 material interests resulting from any scientific, literary or
199 artistic production of which [they are] the author (Art. 27), and
200 privacy (Art. 12)." A partial catalog of human rights related to
201 Information and Communications Technologies, including economic
202 rights, can be found in [Hill2014].
204 This is by no means an attempt to exclude specific rights or
205 prioritize some rights over others.
207 3. Guidelines for developing human rights protocol considerations
209 3.1. Conducting human rights reviews
211 Human rights reviews can take place at different stages of the
212 development process of an Internet-Draft. However, generally
213 speaking, it is easier to influence the development of a technology
214 at earlier stages than at later stages. This does not mean that
215 reviews at last-call are not relevant, but they are less likely to
216 result in significant changes in the reviewed document.
218 Methods for analyzing technology for specific human rights impacts
219 are still quite nascent. Currently, five methods have been explored
220 by the Human Rights Review Team, often in conjunction with each
221 other:
223 3.1.1. Analyzing drafts based on guidelines for human rights
224 considerations model
226 This analysis of Internet-Drafts uses the model as described in
227 section 3.3. The outlined categories and questions can be used to
228 review an Internet-Draft. The advantage of this is that it provides
229 a known overview, and document authors can go back to this document
230 as well as [RFC8280] to understand the background and the context.
232 3.1.2. Analyzing drafts based on their perceived or speculated impact
234 When reviewing an Internet-Draft, specific human rights impacts can
235 become apparent by doing a close reading of the draft and seeking to
236 understand how it might affect networks or society. While less
237 structured than the straight use of the human rights considerations
238 model, this analysis may lead to new speculative understandings of
239 links between human rights and protocols.
241 3.1.3. Expert interviews
243 Interviews with document authors, active members of the Working
244 Group, or experts in the field can help explore the characteristics
245 of the protocol and its effects. There are two main advantages to
246 this approach: one the one hand, it allows the reviewer to gain a
247 deeper understanding of the (intended) workings of the protocol; on
248 the other hand, it also allows for the reviewer to start a discussion
249 with experts or even document authors, which can help the review gain
250 traction when it is published.
252 3.1.4. Interviews with impacted persons and communities
254 Protocols impact users of the Internet. Interviews can help the
255 reviewer understand how protocols affect the people that use the
256 protocols. Since human rights are best understood from the
257 perspective of the rights-holder, this approach will improve the
258 understanding of the real world effects of the technology. At the
259 same time, it can be hard to attribute specific changes to a
260 particular protocol, this is of course even harder when a protocol
261 has not been (widely) deployed.
263 3.1.5. Tracing impacts of implementations
265 The reality of deployed protocols can be at odds with the
266 expectations during the protocol design and development phase
267 [RFC8980]. When a specification already has associated running code,
268 the code can be analyzed either in an experimental setting or on the
269 Internet where its impact can be observed. In contrast to reviewing
270 the draft text, this approach can allow the reviewer to understand
271 how the specifications works in practice, and potentially what
272 unknown or unexpected effects the technology has.
274 3.2. Guidelines for human rights considerations
276 This section provides guidance for document authors in the form of a
277 questionnaire about protocols and how technical decisions can shape
278 the exercise of human rights. The questionnaire may be useful at any
279 point in the design process, particularly after the document authors
280 have developed a high-level protocol model as described in [RFC4101].
281 These guidelines do not seek to replace any existing referenced
282 specifications, but rather contribute to them and look at the design
283 process from a human rights perspective.
285 Protocols and Internet Standards might benefit from a documented
286 discussion of potential human rights risks arising from potential
287 misapplications of the protocol or technology described in the RFC.
288 This might be coupled with an Applicability Statement for that RFC.
290 Note that the guidance provided in this section does not recommend
291 specific practices. The range of protocols developed in the IETF is
292 too broad to make recommendations about particular uses of data or
293 how human rights might be balanced against other design goals.
294 However, by carefully considering the answers to the following
295 questions, document authors should be able to produce a comprehensive
296 analysis that can serve as the basis for discussion on whether the
297 protocol adequately takes specific human rights threats into account.
298 This guidance is meant to help the thought process of a human rights
299 analysis; it does not provide specific directions for how to write a
300 human rights considerations section (following the example set in
301 [RFC6973]).
303 In considering these questions, authors will need to be aware of the
304 potential of technical advances or the passage of time to undermine
305 protections. In general, considerations of rights are likely to be
306 more effective if they are considered given a purpose and specific
307 use cases, rather than as abstract absolute goals.
309 Also note that while the section uses the word, 'protocol', the
310 principles identified in these questions may be applicable to other
311 types of solutions (extensions to existing protocols, architecture
312 for solutions to specific problems, etc.).
314 3.2.1. Connectivity
316 Question(s): Does your protocol add application-specific functions to
317 intermediary nodes? Could this functionality be added to end nodes
318 instead of intermediary nodes? Is your protocol optimized for low
319 bandwidth and high latency connections? Could your protocol also be
320 developed in a stateless manner?
322 Explanation: The end-to-end principle [Saltzer] holds that 'the
323 intelligence is end to end rather than hidden in the network'
324 [RFC1958]. Using the end-to-end principle in protocol design is
325 important to ensure the reliability and security of data
326 transmissions.
328 Considering the fact that network quality and conditions vary across
329 geography and time, it is also important to design protocols such
330 that they are reliable even on low bandwidth and high latency
331 connections.
333 Example: Encrypting connections, like done with HTTPS, can add a
334 significant network overhead and consequently make web resources less
335 accessible to those with low bandwidth and/or high latency
336 connections. [HTTPS-REL] Encrypting traffic is a net positive for
337 privacy and security, and thus protocol designers can acknowledge the
338 tradeoffs of connectivity made by such decisions.
340 Impacts:
342 * Right to freedom of expression
344 * Right to freedom of assembly and association
346 3.2.2. Privacy
348 Question(s): Did you have a look at the Guidelines in the Privacy
349 Considerations for Internet Protocols [RFC6973] section 7? Does your
350 protocol maintain the confidentiality of metadata? Could your
351 protocol counter traffic analysis? Does your protocol adhere to data
352 minimization principles? Does your document identify potentially
353 sensitive data logged by your protocol and/or for how long that needs
354 to be retained for technical reasons?
356 Explanation: Privacy refers to the right of an entity (normally a
357 person), acting on its own behalf, to determine the degree to which
358 it will interact with its environment, including the degree to which
359 the entity is willing to share its personal information with others.
360 [RFC4949]. If a protocol provides insufficient privacy protection it
361 may have a negative impact on freedom of expression as users self-
362 censor for fear of surveillance, or find themselves unable to express
363 themselves freely.
365 Example: See [RFC6973]
367 Impacts:
369 * Right to freedom of expression
371 * Right to non-discrimination
373 3.2.3. Content agnosticism
375 Question(s): If your protocol impacts packet handling, does it use
376 user data (packet data that is not included in the header)? Is it
377 making decisions based on the payload of the packet? Does your
378 protocol prioritize certain content or services over others in the
379 routing process? Is the protocol transparent about the
380 prioritization that is made (if any)?
381 Explanation: Content agnosticism refers to the notion that network
382 traffic is treated identically regardless of payload, with some
383 exceptions where it comes to effective traffic handling, for instance
384 where it comes to delay-tolerant or delay-sensitive packets, based on
385 the header.
387 Example: Content agnosticism prevents payload-based discrimination
388 against packets. This is important because changes to this principle
389 can lead to a two-tiered Internet, where certain packets are
390 prioritized over others on the basis of their content. Effectively
391 this would mean that although all users are entitled to receive their
392 packets at a certain speed, some users become more equal than others.
394 Impacts:
396 * Right to freedom of expression
398 * Right to non-discrimination
400 * Right to equal protection
402 3.2.4. Security
404 Question(s): Did you have a look at Guidelines for Writing RFC Text
405 on Security Considerations [BCP72]? Have you found any attacks that
406 are somewhat related to your protocol/specification, yet considered
407 out of scope of your document? Would these attacks be pertinent to
408 the human rights enabling features of the Internet (as described
409 throughout this document)?
411 Explanation: Security is not a single monolithic property of a
412 protocol or system, but rather a series of related but somewhat
413 independent properties. Not all of these properties are required for
414 every application. Since communications are carried out by systems
415 and access to systems is through communications channels, security
416 goals obviously interlock, but they can also be independently
417 provided. [BCP72].
419 Example: See [BCP72].
421 Impacts:
423 * Right to freedom of expression
425 * Right to freedom of assembly and association
427 * Right to non-discrimination
428 * Right to security
430 3.2.5. Internationalization
432 Question(s): Does your protocol or specification define text string
433 elements, in the payload or headers, that have to be understood or
434 entered by humans? Does your specification allow Unicode? If so, do
435 you accept texts in one charset (which must be UTF-8), or several
436 (which is dangerous for interoperability)? If character sets or
437 encodings other than UTF-8 are allowed, does your specification
438 mandate a proper tagging of the charset? Did you have a look at
439 [RFC6365]?
441 Explanation: Internationalization refers to the practice of making
442 protocols, standards, and implementations usable in different
443 languages and scripts (see Localization). In the IETF,
444 internationalization means to add or improve the handling of non-
445 ASCII text in a protocol. [RFC6365] A different perspective, more
446 appropriate to protocols that are designed for global use from the
447 beginning, is the definition used by W3C:
449 "Internationalization is the design and development of a
450 product, application or document content that enables easy
451 localization for target audiences that vary in culture, region,
452 or language." {{W3Ci18nDef}}
454 Many protocols that handle text only handle one charset (US-ASCII),
455 or leave the question of what coded character set and encoding are
456 used up to local guesswork (which leads, of course, to
457 interoperability problems). If multiple charsets are permitted, they
458 must be explicitly identified [RFC2277]. Adding non-ASCII text to a
459 protocol allows the protocol to handle more scripts, hopefully
460 representing users across the world. In today's world, that is
461 normally best accomplished by allowing Unicode encoded in UTF-8 only.
463 In the current IETF policy [RFC2277], internationalization is aimed
464 at user-facing strings, not protocol elements, such as the verbs used
465 by some text-based protocols. (Do note that some strings are both
466 content and protocol elements, such as the identifiers.) Given the
467 IETF's mission to make the Internet a global network of networks,
468 [RFC3935] developers should ensure that protocols work with languages
469 apart from English and character sets apart from Latin characters.
470 It is therefore crucial that at least the content carried by the
471 protocol can be in any script, and that all scripts are treated
472 equally.
474 Example: See localization
475 Impacts:
477 * Right to freedom of expression
479 * Right to political participation
481 * Right to participate in cultural life, arts and science
483 3.2.6. Censorship resistance
485 Question(s): Does your protocol make it apparent or transparent when
486 access to a resource is restricted and reasons therefor? Can your
487 protocol contribute to filtering in a way it could be implemented to
488 censor data or services? Could this be designed to ensure this
489 doesn't happen? Does your protocol introduce new identifiers or
490 reuse existing identifiers (e.g. MAC addresses) that might be
491 associated with persons or content?
493 Explanation: Censorship resistance refers to the methods and measures
494 to prevent Internet censorship. See [draft-irtf-pearg-censorship]
495 for a survey of censorship techniques employed across the world,
496 which lays out protocol properties that have been exploited to censor
497 access to information.
499 Example: Identifiers of content exposed within a protocol might be
500 used to facilitate censorship, as in the case of Application Layer
501 based censorship, which affects protocols like HTTP. In HTTP, denial
502 or restriction of access can be made apparent by the use of status
503 code 451, which allows server operators to operate with greater
504 transparency in circumstances where issues of law or public policy
505 affect their operation [RFC7725].
507 If a protocol potentially enables censorship, protocol designers
508 should strive towards creating error codes that capture different
509 scenarios (blocked due to administrative policy, unavailable because
510 of legal requirements, etc.) to minimize ambiguity for end-users.
512 In the development of the IPv6 protocol, it was discussed to embed a
513 Media Access Control (MAC) address into unique IP addresses. This
514 would make it possible for 'eavesdroppers and other information
515 collectors to identify when different addresses used in different
516 transactions actually correspond to the same node. This is why
517 standardisation efforts like Privacy Extensions for Stateless Address
518 Autoconfiguration in IPv6 [RFC4941] and MAC address randomization
519 [draft-zuniga-mac-address-randomization] have been pursued.
521 Impacts:
523 * Right to freedom of expression
525 * Right to political participation
527 * Right to participate in cultural life, arts, and science
529 * Right to freedom of assembly and association
531 3.2.7. 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."
562 Open standards (and open source software) allow users to glean
563 information about how the tools they are using work, including the
564 tools' security and privacy properties. They additionally allow for
565 permissionless innovation, which is important to maintain the freedom
566 and ability to freely create and deploy new protocols on top of the
567 communications constructs that currently exist. It is at the heart
568 of the Internet as we know it, and to maintain its fundamentally open
569 nature, we need to be mindful of the need for developing open
570 standards.
572 All standards that need to be normatively implemented should be
573 freely available and with reasonable protection for patent
574 infringement claims, so it can also be implemented in open source or
575 free software. Patents have often held back open standardization or
576 been used against those deploying open standards, particularly in the
577 domain of cryptography [newegg]. An exemption of this is sometimes
578 made when a protocol is standardized that normatively relies on
579 specifications produced by others SDOs that are not freely available.
580 Patents in open standards or in normative references to other
581 standards should have a patent disclosure [notewell], royalty-free
582 licensing [patentpolicy], or some other form of fair, reasonable and
583 non-discriminatory terms.
585 Example: [RFC6108] describes a system for providing critical end-user
586 notifications to web browsers, which has been deployed by Comcast, an
587 Internet Service Provider (ISP). Such a notification system is being
588 used to provide near-immediate notifications to customers, such as to
589 warn them that their traffic exhibits patterns that are indicative of
590 malware or virus infection. There are other proprietary systems that
591 can perform such notifications, but those systems utilize Deep Packet
592 Inspection (DPI) technology. In contrast, that document describes a
593 system that does not rely upon DPI, and is instead based on open IETF
594 standards and open source applications.
596 Impacts:
598 * Right to freedom of expression
600 * Right to participate in cultural life, arts and science
602 3.2.8. Heterogeneity Support
604 Question(s): Does your protocol support heterogeneity by design?
605 Does your protocol allow for multiple types of hardware? Does your
606 protocol allow for multiple types of application protocols? Is your
607 protocol liberal in what it receives and handles? Will it remain
608 usable and open if the context changes? Does your protocol allow
609 there to be well-defined extension points? Do these extension points
610 allow for open innovation?
612 Explanation: The Internet is characterized by heterogeneity on many
613 levels: devices and nodes, router scheduling algorithms and queue
614 management mechanisms, routing protocols, levels of multiplexing,
615 protocol versions and implementations, underlying link layers (e.g.,
616 point-to-point, multi-access links, wireless, FDDI, etc.), in the
617 traffic mix and in the levels of congestion at different times and
618 places. Moreover, as the Internet is composed of autonomous
619 organizations and Internet service providers, each with their own
620 separate policy concerns, there is a large heterogeneity of
621 administrative domains and pricing structures. As a result, the
622 heterogeneity principle proposed in [RFC1958] needs to be supported
623 by design [FIArch].
625 Heterogeneity support in protocols can thus enable a wide range of
626 devices and (by extension) users to participate on the network.
628 Example: Heterogeneity is inevitable and needs be supported by
629 design. Multiple types of hardware must be allowed for, e.g.
630 transmission speeds differing by at least 7 orders of magnitude,
631 various computer word lengths, and hosts ranging from memory-starved
632 microprocessors up to massively parallel supercomputers. Multiple
633 types of application protocols must be allowed for, ranging from the
634 simplest such as remote login up to the most complex such as commit
635 protocols for distributed databases. [RFC1958].
637 Impacts:
639 * Right to freedom of expression
641 * Right to political participation
643 3.2.9. Pseudonymity
645 Question(s): Have you considered the Privacy Considerations for
646 Internet Protocols [RFC6973], especially section 6.1.2 ? Does the
647 protocol collect personally derived data? Does the protocol generate
648 or process anything that can be, or be tightly correlated with,
649 personally identifiable information? Does the protocol utilize data
650 that is personally-derived, i.e. derived from the interaction of a
651 single person, or their device or address? Does this protocol
652 generate personally derived data, and if so how will that data be
653 handled?
655 Explanation: Pseudonymity - the ability to use a persistent
656 identifier not linked to one's offline identity - is an important
657 feature for many end-users, as it allows them different degrees of
658 disguised identity and privacy online. This can allow an enabling
659 environment for users to exercise other rights, including freedom of
660 expression and political participation, without fear or direct
661 identification or discrimination.
663 Example: While designing a standard that exposes personal data, it is
664 important to consider ways to mitigate the obvious impacts. While
665 pseudonyms cannot be simply reverse engineered - some early
666 approaches simply took approaches such as simple hashing of IP
667 addresses, these could then be simply reversed by generating a hash
668 for each potential IP address and comparing it to the pseudonym -
669 limiting the exposure of personal data remains important.
671 Pseudonymity means using a pseudonym instead of one's "real" name.
672 There are many reasons for users to use pseudonyms, for instance to:
673 hide their gender, protect themselves against harassment, protect
674 their families' privacy, frankly discuss sexuality, or develop an
675 artistic or journalistic persona without repercussions from an
676 employer, (potential) customers, or social surrounding.
677 [geekfeminism] The difference between anonymity and pseudonymity is
678 that a pseudonym often is persistent. "Pseudonymity is strengthened
679 when less personal data can be linked to the pseudonym; when the same
680 pseudonym is used less often and across fewer contexts; and when
681 independently chosen pseudonyms are more frequently used for new
682 actions (making them, from an observer's or attacker's perspective,
683 unlinkable)." [RFC6973]
685 Impacts:
687 * Right to non-discrimination
689 * Right to freedom of expression
690 * Right to political participation
692 * Right to freedom of assembly and association
694 3.2.10. Anonymity
696 Question(s): Does your protocol make use of persistent identifiers?
697 Can it be done without them? Did you have a look at the Privacy
698 Considerations for Internet Protocols [RFC6973], especially section
699 6.1.1 of that document?
701 Explanation: Anonymity refers to the condition of an identity being
702 unknown or concealed [RFC4949]. Even though full anonymity is hard
703 to achieve, it is a non-binary concept. Making pervasive monitoring
704 and tracking harder is important for many users as well as for the
705 IETF [RFC7258]. Achieving a higher level of anonymity is an
706 important feature for many end-users, as it allows them different
707 degrees of privacy online. Anonymity is an inherent part of the
708 right to freedom of opinion and expression and the right to privacy.
709 Avoid adding identifiers, options or configurations that create or
710 might lead to patterns or regularities that are not explicitly
711 required by the protocol.
713 If your protocol collects data and distributes it (see [RFC6235]),
714 you should anonymize the data, but keep in mind that "anonymizing"
715 data is notoriously hard. Do not think that just dropping the last
716 byte of an IP address "anonymizes" data. If your protocol allows for
717 identity management, there should be a clear barrier between the
718 identities to ensure that they cannot (easily) be associated with
719 each other.
721 Often protocols expose personal data, it is important to consider
722 ways to mitigate the obvious privacy impacts. A protocol that uses
723 data that could help identify a sender (items of interest) should be
724 protected from third parties. For instance, if one wants to hide the
725 source/destination IP addresses of a packet, the use of IPsec in
726 tunneling mode (e.g., inside a virtual private network) can be
727 helpful to protect from third parties likely to eavesdrop packets
728 exchanged between the tunnel endpoints.
730 Example: An example is DHCP where sending a persistent identifier as
731 the client name was not mandatory but, in practice, done by many
732 implementations, before [RFC7844].
734 Impacts:
736 * Right to non-discrimination
737 * Right to political participation
739 * Right to freedom of assembly and association
741 * Right to security
743 3.2.11. Accessibility
745 Question(s): Is your protocol designed to provide an enabling
746 environment for all? Have you looked at the W3C Web Accessibility
747 Initiative for examples and guidance?
749 Explanation: Sometimes in the design of protocols, websites, web
750 technologies, or web tools, barriers are created that exclude people
751 from using the Web. The Internet should be designed to work for all
752 people, whatever their hardware, software, language, culture,
753 location, or physical or mental ability. When the Internet
754 technologies meet this goal, it will be accessible to people with a
755 diverse range of hearing, movement, sight, and cognitive ability.
756 [W3CAccessibility]
758 Example: The HTML protocol as defined in [HTML5] specifically
759 requires that every image must have an alt attribute (with a few
760 exceptions) to ensure images are accessible for people that cannot
761 themselves decipher non-text content in web pages.
763 Impacts:
765 * Right to non-discrimination
767 * Right to freedom of assembly and association
769 * Right to education
771 * Right to political participation
773 3.2.12. Localization
775 Question(s): Does your protocol uphold the standards of
776 internationalization? Have you made any concrete steps towards
777 localizing your protocol for relevant audiences?
778 Explanation: Localization refers to the adaptation of a product,
779 application or document content to meet the language, cultural and
780 other requirements of a specific target market (a locale)
781 [W3Ci18nDef]. For our purposes, it can be described as the practice
782 of translating an implementation to make it functional in a specific
783 language or for users in a specific locale (see
784 Internationalization).
786 Example: The Internet is a global medium, but many of its protocols
787 and products are developed with a certain audience in mind, that
788 often share particular characteristics like knowing how to read and
789 write in ASCII and knowing English. This limits the ability of a
790 large part of the world's online population from using the Internet
791 in a way that is culturally and linguistically accessible. An
792 example of a protocol that has taken into account the view that
793 individuals like to have access to data in their native language can
794 be found in [RFC5646]. This protocol labels the information content
795 with an identifier for the language in which it is written. And this
796 allows information to be presented in more than one language.
798 Impacts:
800 * Right to non-discrimination
802 * Right to participate in cultural life, arts and science
804 * Right to freedom of expression
806 3.2.13. Decentralization
808 Question(s): Can your protocol be implemented without a single point
809 of control? If applicable, can your protocol be deployed in a
810 federated manner? What is the potential for discrimination against
811 users of your protocol? How can your protocol be used to implicate
812 users? Does your protocol create additional centralized points of
813 control?
815 Explanation: Decentralization is one of the central technical
816 concepts of the architecture of the networks, and is embraced as such
817 by the IETF [RFC3935]. It refers to the absence or minimization of
818 centralized points of control, a feature that is assumed to make it
819 easy for new users to join and new uses to unfold [Brown]. It also
820 reduces issues surrounding single points of failure, and distributes
821 the network such that it continues to function even if one or several
822 nodes are disabled. With the commercialization of the Internet in
823 the early 1990s, there has been a slow move away from
824 decentralization, to the detriment of the technical benefits of
825 having a decentralized Internet.
827 Example: The bits traveling the Internet are increasingly susceptible
828 to monitoring and censorship, from both governments and Internet
829 service providers, as well as third (malicious) parties. The ability
830 to monitor and censor is further enabled by the increased
831 centralization of the network that creates central infrastructure
832 points that can be tapped into. The creation of peer-to-peer
833 networks and the development of voice-over-IP protocols using peer-
834 to-peer technology in combination with distributed hash table (DHT)
835 for scalability are examples of how protocols can preserve
836 decentralization [Pouwelse].
838 Impacts:
840 * Right to freedom of expression
842 * Right to freedom of assembly and association
844 3.2.14. Reliability
846 Question(s): Is your protocol fault tolerant? Does it downgrade
847 gracefully, i.e. with mechanisms for fallback and/or notice? Can
848 your protocol resist malicious degradation attempts? Do you have a
849 documented way to announce degradation? Do you have measures in
850 place for recovery or partial healing from failure? Can your
851 protocol maintain dependability and performance in the face of
852 unanticipated changes or circumstances?
854 Explanation: Reliability and resiliency ensures that a protocol will
855 execute its function consistently and error resistant as described,
856 and function without unexpected result. A system that is reliable
857 degrades gracefully and will have a documented way to announce
858 degradation. It also has mechanisms to recover from failure
859 gracefully, and if applicable, allow for partial healing.
861 It is important here to draw a distinction between random degradation
862 and malicious degradation. Many current attacks against TLS, for
863 example, exploit TLS' ability to gracefully downgrade to older cipher
864 suites - from a functional perspective, this is useful; from a
865 security perspective, this can be disastrous. As with
866 confidentiality, the growth of the Internet and fostering innovation
867 in services depends on users having confidence and trust [RFC3724] in
868 the network. For reliability, it is necessary that services notify
869 the users if a delivery fails. In the case of real-time systems in
870 addition to the reliable delivery the protocol needs to safeguard
871 timeliness.
873 Example: In the modern IP stack structure, a reliable transport layer
874 requires an indication that transport processing has successfully
875 completed, such as given by TCP's ACK message [RFC0793], and not
876 simply an indication from the IP layer that the packet arrived.
877 Similarly, an application layer protocol may require an application-
878 specific acknowledgment that contains, among other things, a status
879 code indicating the disposition of the request (See [RFC3724]).
881 Impacts:
883 * Right to freedom of expression
885 * Right to security
887 3.2.15. Confidentiality
889 Question(s): Does this protocol expose information related to
890 identifiers or data? If so, does it do so to each other protocol
891 entity (i.e., recipients, intermediaries, and enablers) [RFC6973]?
892 What options exist for protocol implementers to choose to limit the
893 information shared with each entity? What operational controls are
894 available to limit the information shared with each entity?
896 What controls or consent mechanisms does the protocol define or
897 require before personal data or identifiers are shared or exposed via
898 the protocol? If no such mechanisms or controls are specified, is it
899 expected that control and consent will be handled outside of the
900 protocol?
902 Does the protocol provide ways for initiators to share different
903 pieces of information with different recipients? If not, are there
904 mechanisms that exist outside of the protocol to provide initiators
905 with such control?
907 Does the protocol provide ways for initiators to limit the sharing or
908 express individuals' preferences to recipients or intermediaries with
909 regard to the collection, use, or disclosure of their personal data?
910 If not, are there mechanisms that exist outside of the protocol to
911 provide users with such control? Is it expected that users will have
912 relationships that govern the use of the information (contractual or
913 otherwise) with those who operate these intermediaries? Does the
914 protocol prefer encryption over clear text operation?
916 Explanation: Confidentiality refers to keeping your data secret from
917 unintended listeners [BCP72]. The growth of the Internet depends on
918 users having confidence that the network protects their personal data
919 [RFC1984].
921 Example: Protocols that do not encrypt their payload make the entire
922 content of the communication available to the idealized attacker
923 along their path. Following the advice in [RFC3365], most such
924 protocols have a secure variant that encrypts the payload for
925 confidentiality, and these secure variants are seeing ever-wider
926 deployment. A noteworthy exception is DNS [RFC1035], as DNSSEC
927 [RFC4033] does not have confidentiality as a requirement. This
928 implies that, in the absence of the use of more recent standards like
929 DNS over TLS [RFC7858] or DNS over HTTPS [RFC8484], all DNS queries
930 and answers generated by the activities of any protocol are available
931 to the attacker. When store-and-forward protocols are used (e.g.,
932 SMTP [RFC5321]), intermediaries leave this data subject to
933 observation by an attacker that has compromised these intermediaries,
934 unless the data is encrypted end-to-end by the application-layer
935 protocol or the implementation uses an encrypted store for this data
936 [RFC7624].
938 Impacts:
940 * Right to privacy
942 * Right to security
944 3.2.16. Integrity
946 Question(s): Does your protocol maintain, assure and/or verify the
947 accuracy of payload data? Does your protocol maintain and assure the
948 consistency of data? Does your protocol in any way allow for the
949 data to be (intentionally or unintentionally) altered?
951 Explanation: Integrity refers to the maintenance and assurance of the
952 accuracy and consistency of data to ensure it has not been
953 (intentionally or unintentionally) altered.
955 Example: Integrity verification of data is important to prevent
956 vulnerabilities and attacks from on-path attackers. These attacks
957 happen when a third party (often for malicious reasons) intercepts a
958 communication between two parties, inserting themselves in the middle
959 changing the content of the data. In practice this looks as follows:
961 Alice wants to communicate with Bob. Corinne forges and sends a
962 message to Bob, impersonating Alice. Bob cannot see the data from
963 Alice was altered by Corinne. Corinne intercepts and alters the
964 communication as it is sent between Alice and Bob. Corinne is able to
965 control the communication content.
967 Impacts:
969 * Right to freedom of expression
971 * Right to security
973 3.2.17. Authenticity
975 Question(s): Do you have sufficient measures to confirm the truth of
976 an attribute of a single piece of data or entity? Can the attributes
977 get garbled along the way (see security)? If relevant, have you
978 implemented IPsec, DNSsec, HTTPS and other Standard Security Best
979 Practices?
981 Explanation: Authenticity ensures that data does indeed come from the
982 source it claims to come from. This is important to prevent certain
983 attacks or unauthorized access and use of data.
985 At the same time, authentication should not be used as a way to
986 prevent heterogeneity support, as is often done for vendor lock-in or
987 digital rights management.
989 Example: Authentication of data is important to prevent
990 vulnerabilities, and attacks from on-path attackers. These attacks
991 happen when a third party (often for malicious reasons) intercepts a
992 communication between two parties, inserting themselves in the middle
993 and posing as both parties. In practice this looks as follows:
995 Alice wants to communicate with Bob. Alice sends data to Bob. Corinne
996 intercepts the data sent to Bob. Corinne reads (and potentially
997 alters) the message to Bob. Bob cannot see the data did not come from
998 Alice but from Corinne.
1000 When there is proper authentication the scenario would be as follows:
1002 Alice wants to communicate with Bob. Alice sends data to Bob. Corinne
1003 intercepts the data sent to Bob. Corinne reads and alters the message
1004 to Bob. Bob can see the data did not come from Alice.
1006 Impacts:
1008 * Right to privacy
1010 * Right to freedom of expression
1012 * Right to security
1014 3.2.18. Adaptability
1016 Question(s): Is your protocol written in such a way that it would be
1017 easy for other protocols to be developed on top of it, or to interact
1018 with it? Does your protocol impact permissionless innovation? (See
1019 Open Standards)
1021 Explanation: Adaptability is closely interrelated with permissionless
1022 innovation: both maintain the freedom and ability to freely create
1023 and deploy new protocols on top of the communications constructs that
1024 currently exist. It is at the heart of the Internet as we know it,
1025 and to maintain its fundamentally open nature, we need to be mindful
1026 of the impact of protocols on maintaining or reducing permissionless
1027 innovation to ensure the Internet can continue to develop.
1029 Example: WebRTC generates audio and/or video data. In order to
1030 ensure that WebRTC can be used in different locations by different
1031 parties, it is important that standard Javascript APIs are developed
1032 to support applications from different voice service providers.
1033 Multiple parties will have similar capabilities, in order to ensure
1034 that all parties can build upon existing standards these need to be
1035 adaptable, and allow for permissionless innovation.
1037 Impacts:
1039 * Right to education
1041 * Freedom of expression
1043 * Freedom of assembly and association
1045 3.2.19. Outcome Transparency
1047 Question(s): Are the effects of your protocol fully and easily
1048 comprehensible, including with respect to unintended consequences of
1049 protocol choices?
1051 Explanation: Certain technical choices may have unintended
1052 consequences.
1054 Example: Lack of authenticity may lead to lack of integrity and
1055 negative externalities, of which spam is an example. Lack of data
1056 that could be used for billing and accounting can lead to so-called
1057 "free" arrangements which obscure the actual costs and distribution
1058 of the costs, for example the barter arrangements that are commonly
1059 used for Internet interconnection; and the commercial exploitation of
1060 personal data for targeted advertising which is the most common
1061 funding model for the so-called "free" services such as search
1062 engines and social networks. Other unexpected outcomes might not be
1063 technical, but rather architectural, social or economical.
1065 Impacts:
1067 * Freedom of expression
1069 * Privacy
1071 * Freedom of assembly and association
1073 * Access to information
1075 3.2.20. Remedy
1077 Question(s): Can your protocol facilitate a negatively impacted
1078 party's right to remedy without disproportionately impacting other
1079 parties' human rights, especially their right to privacy?
1081 Explanation: Access to remedy may help victims of human rights
1082 violations in seeking justice, or allow law enforcement agencies to
1083 identify a possible violator. However, such mechanisms may impede
1084 the exercise of the right to privacy. The former Special Rapporteur
1085 for Freedom of Expression has also argued that anonymity is an
1086 inherent part of freedom of expression [Kaye]. Considering the
1087 potential adverse impact of attribution on the right to privacy and
1088 freedom of expression, enabling attribution on an individual level is
1089 most likely not consistent with human rights. However, providing
1090 access to remedy by states and corporations is an inherent part of
1091 the UN Guiding Principles on Business and Human Rights [UNGP].
1093 Impacts:
1095 * Right to remedy
1097 * Right to security
1099 * Right to privacy
1101 3.2.21. Misc. considerations
1103 Question(s): Have you considered potential negative consequences
1104 (individual or societal) that your protocol or document might have?
1106 Explanation: Publication of a particular RFC under a certain status
1107 has consequences. Publication as an Internet Standard as part of the
1108 Standards Track may signal to implementers that the specification has
1109 a certain level of maturity, operational experience, and consensus.
1110 Similarly, publication of a specification an experimental document as
1111 part of the non-standards track would signal to the community that
1112 the document "may be intended for eventual standardization but [may]
1113 not yet [be] ready" for wide deployment. The extent of the
1114 deployment, and consequently its overall impact on end-users, may
1115 depend on the document status presented in the RFC. See [BCP9] and
1116 updates to it for a fuller explanation.
1118 4. Document Status
1120 This RG document is currently documenting best practices and
1121 guidelines for human rights reviews of network protocols,
1122 architectures and other Internet-Drafts and RFCs.
1124 5. Acknowledgements
1126 Thanks to:
1128 * Corinne Cath-Speth for work on [RFC8280].
1130 * Theresa Engelhard, Joe Hall, Avri Doria, Joey Salazar, Corinne
1131 Cath-Speth, Farzaneh Badii, Sandra Braman and the hrpc list for
1132 reviews and suggestions.
1134 * Individuals who conducted human rights reviews for their work and
1135 feedback: Amelia Andersdotter, Beatrice Martini, Karan Saini and
1136 Shivan Kaul Sahib.
1138 6. Security Considerations
1140 Article three of the Universal Declaration of Human Rights reads:
1141 "Everyone has the right to life, liberty and security of person.".
1142 This article underlines the importance of security and its
1143 interrelation with human life and liberty, but since human rights are
1144 indivisible, interrelated and interdependent, security is also
1145 closely linked to other human rights and freedoms. This document
1146 seeks to strengthen human rights, freedoms, and security by relating
1147 and translating these concepts to concepts and practices as they are
1148 used in Internet protocol and architecture development. The aim of
1149 this is to secure human right and thereby improve the susainability,
1150 usability, and effectiveness of the network. The document seeks to
1151 achieve this by providing guidelines as done in section three of this
1152 document.
1154 7. IANA Considerations
1156 This document has no actions for IANA.
1158 8. Research Group Information
1160 The discussion list for the IRTF Human Rights Protocol Considerations
1161 Research Group is located at the e-mail address hrpc@ietf.org
1162 (mailto:hrpc@ietf.org). Information on the group and information on
1163 how to subscribe to the list is at
1164 https://www.irtf.org/mailman/listinfo/hrpc
1165 (https://www.irtf.org/mailman/listinfo/hrpc)
1167 Archives of the list can be found at: https://www.irtf.org/mail-
1168 archive/web/hrpc/current/index.html (https://www.irtf.org/mail-
1169 archive/web/hrpc/current/index.html)
1171 9. Informative References
1173 [BCP72] IETF, "Guidelines for Writing RFC Text on Security
1174 Considerations", 2003,
1175 .
1177 [BCP9] Bradner, S. and IETF, "The Internet Standards Process --
1178 Revision 3", 1996,
1179 .
1181 [Bless] Bless, R. and C. Orwat, "Values and Networks", 2015.
1183 [Brown] Brown, I. and M. Ziewitz, "A Prehistory of Internet
1184 Governance", Research Handbook on Governance of the
1185 Internet. Cheltenham, Edward Elgar. , 2013.
1187 [draft-irtf-pearg-censorship]
1188 Hall, J., Aaron, M., Adams, S., Jones, B., and N.
1189 Feamster, "A Survey of Worldwide Censorship Techniques",
1190 2020,
1191 .
1193 [draft-zuniga-mac-address-randomization]
1194 Zuniga, JC., Bernardos, CJ., and A. Andersdotter, "MAC
1195 address randomization", 2020,
1196 .
1198 [FIArch] "Future Internet Design Principles", January 2012,
1199 .
1202 [geekfeminism]
1203 Geek Feminism Wiki, "Pseudonymity", 2015,
1204 .
1206 [Hill2014] Hill, R., "Partial Catalog of Human Rights Related to ICT
1207 Activities", 2014,
1208 .
1210 [HTML5] W3C, "HTML5", 2014, .
1212 [HTTPS-REL]
1213 Meyer, E., "Securing Web Sites Made Them Less Accessible",
1214 2018, .
1217 [ICCPR] United Nations General Assembly, "International Covenant
1218 on Civil and Political Rights", 1976,
1219 .
1222 [ICESCR] United Nations General Assembly, "International Covenant
1223 on Economic, Social and Cultural Rights", 1966,
1224 .
1227 [IRP] Internet Rights and Principles Dynamic Coalition, "10
1228 Internet Rights & Principles", 2014,
1229 .
1233 [Kaye] Kaye, D., "The use of encryption and anonymity in digital
1234 communications", 2015,
1235 .
1238 [newegg] Mullin, J., "Newegg on trial: Mystery company TQP rewrites
1239 the history of encryption", 2013, .
1243 [notewell] IETF, "Note Well", 2015,
1244 .
1246 [patentpolicy]
1247 W3C, "W3C Patent Policy", 2004,
1248 .
1250 [Penney] Penney, J., "Chilling Effects: Online Surveillance and
1251 Wikipedia Use", 2016, .
1254 [Pouwelse] Pouwelse, Ed, J., "Media without censorship", 2012,
1255 .
1258 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
1259 RFC 793, DOI 10.17487/RFC0793, September 1981,
1260 .
1262 [RFC1035] Mockapetris, P., "Domain names - implementation and
1263 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
1264 November 1987, .
1266 [RFC1958] Carpenter, B., Ed., "Architectural Principles of the
1267 Internet", RFC 1958, DOI 10.17487/RFC1958, June 1996,
1268 .
1270 [RFC1984] IAB and IESG, "IAB and IESG Statement on Cryptographic
1271 Technology and the Internet", BCP 200, RFC 1984,
1272 DOI 10.17487/RFC1984, August 1996,
1273 .
1275 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
1276 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996,
1277 .
1279 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
1280 Languages", BCP 18, RFC 2277, DOI 10.17487/RFC2277,
1281 January 1998, .
1283 [RFC3365] Schiller, J., "Strong Security Requirements for Internet
1284 Engineering Task Force Standard Protocols", BCP 61,
1285 RFC 3365, DOI 10.17487/RFC3365, August 2002,
1286 .
1288 [RFC3724] Kempf, J., Ed., Austein, R., Ed., and IAB, "The Rise of
1289 the Middle and the Future of End-to-End: Reflections on
1290 the Evolution of the Internet Architecture", RFC 3724,
1291 DOI 10.17487/RFC3724, March 2004,
1292 .
1294 [RFC3935] Alvestrand, H., "A Mission Statement for the IETF",
1295 BCP 95, RFC 3935, DOI 10.17487/RFC3935, October 2004,
1296 .
1298 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
1299 Rose, "DNS Security Introduction and Requirements",
1300 RFC 4033, DOI 10.17487/RFC4033, March 2005,
1301 .
1303 [RFC4101] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101,
1304 DOI 10.17487/RFC4101, June 2005,
1305 .
1307 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
1308 Extensions for Stateless Address Autoconfiguration in
1309 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
1310 .
1312 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
1313 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
1314 .
1316 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
1317 DOI 10.17487/RFC5321, October 2008,
1318 .
1320 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying
1321 Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646,
1322 September 2009, .
1324 [RFC6108] Chung, C., Kasyanov, A., Livingood, J., Mody, N., and B.
1325 Van Lieu, "Comcast's Web Notification System Design",
1326 RFC 6108, DOI 10.17487/RFC6108, February 2011,
1327 .
1329 [RFC6235] Boschi, E. and B. Trammell, "IP Flow Anonymization
1330 Support", RFC 6235, DOI 10.17487/RFC6235, May 2011,
1331 .
1333 [RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in
1334 Internationalization in the IETF", BCP 166, RFC 6365,
1335 DOI 10.17487/RFC6365, September 2011,
1336 .
1338 [RFC6701] Farrel, A. and P. Resnick, "Sanctions Available for
1339 Application to Violators of IETF IPR Policy", RFC 6701,
1340 DOI 10.17487/RFC6701, August 2012,
1341 .
1343 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
1344 Morris, J., Hansen, M., and R. Smith, "Privacy
1345 Considerations for Internet Protocols", RFC 6973,
1346 DOI 10.17487/RFC6973, July 2013,
1347 .
1349 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
1350 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
1351 2014, .
1353 [RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T.,
1354 Trammell, B., Huitema, C., and D. Borkmann,
1355 "Confidentiality in the Face of Pervasive Surveillance: A
1356 Threat Model and Problem Statement", RFC 7624,
1357 DOI 10.17487/RFC7624, August 2015,
1358 .
1360 [RFC7725] Bray, T., "An HTTP Status Code to Report Legal Obstacles",
1361 RFC 7725, DOI 10.17487/RFC7725, February 2016,
1362 .
1364 [RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity
1365 Profiles for DHCP Clients", RFC 7844,
1366 DOI 10.17487/RFC7844, May 2016,
1367 .
1369 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
1370 and P. Hoffman, "Specification for DNS over Transport
1371 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
1372 2016, .
1374 [RFC8179] Bradner, S. and J. Contreras, "Intellectual Property
1375 Rights in IETF Technology", BCP 79, RFC 8179,
1376 DOI 10.17487/RFC8179, May 2017,
1377 .
1379 [RFC8280] ten Oever, N. and C. Cath, "Research into Human Rights
1380 Protocol Considerations", RFC 8280, DOI 10.17487/RFC8280,
1381 October 2017, .
1383 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
1384 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
1385 .
1387 [RFC8980] Arkko, J. and T. Hardie, "Report from the IAB Workshop on
1388 Design Expectations vs. Deployment Reality in Protocol
1389 Development", RFC 8980, DOI 10.17487/RFC8980, February
1390 2021, .
1392 [Saltzer] Saltzer, J.H., Reed, D.P., and D.D. Clark, "End-to-End
1393 Arguments in System Design", ACM TOCS, Vol 2, Number 4,
1394 November 1984, pp 277-288. , 1984.
1396 [UDHR] United Nations General Assembly, "The Universal
1397 Declaration of Human Rights", 1948,
1398 .
1400 [UNGP] United Nations, "United Nations Guiding Principles on
1401 Business and Human Rights", 2011,
1402 .
1405 [UNHRC2016]
1406 United Nations Human Rights Council, "UN Human Rights
1407 Council Resolution "The promotion, protection and
1408 enjoyment of human rights on the Internet" (A/HRC/32/
1409 L.20)", 2016, .
1413 [W3CAccessibility]
1414 W3C, "Accessibility", 2015,
1415 .
1417 [W3Ci18nDef]
1418 W3C, "Localization vs. Internationalization", 2010,
1419 .
1421 [Zittrain] Zittrain, J., "The Future of the Internet - And How to
1422 Stop It", Yale University Press , 2008,
1423 .
1426 Authors' Addresses
1428 Gurshabad Grover
1429 Centre for Internet and Society
1431 Email: gurshabad@cis-india.org
1433 Niels ten Oever
1434 University of Amsterdam
1436 Email: mail@nielstenoever.net