RFC 8280
Research into Human Rights Protocol Considerations
Internet Research Task Force (IRTF) N. ten Oever Request for Comments: 8280 ARTICLE 19 Category: Informational C. Cath ISSN: 2070-1721 Oxford Internet Institute October 2017 Research into Human Rights Protocol ConsiderationsAbstract
This document aims to propose guidelines for human rights considerations, similar to the work done on the guidelines for privacy considerations (RFC 6973). The other parts of this document explain the background of the guidelines and how they were developed. This document is the first milestone in a longer-term research effort. It has been reviewed by the Human Rights Protocol Considerations (HRPC) Research Group and also by individuals from outside the research group. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the consensus of the Human Rights Protocol Considerations Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not a candidate for any level of Internet Standard; see Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8280.
Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
Table of Contents
1. Introduction ....................................................4 2. Vocabulary Used .................................................6 3. Research Questions .............................................12 4. Literature and Discussion Review ...............................12 5. Methodology ....................................................15 5.1. Data Sources ..............................................17 5.1.1. Discourse Analysis of RFCs .........................17 5.1.2. Interviews with Members of the IETF Community ......17 5.1.3. Participant Observation in Working Groups ..........17 5.2. Data Analysis Strategies ..................................18 5.2.1. Identifying Qualities of Technical Concepts That Relate to Human Rights ........................18 5.2.2. Relating Human Rights to Technical Concepts ........20 5.2.3. Mapping Cases of Protocols, Implementations, and Networking Paradigms That Adversely Impact Human Rights or Are Enablers Thereof .....................21 6. Model for Developing Human Rights Protocol Considerations ......40 6.1. Human Rights Threats ......................................40 6.2. Guidelines for Human Rights Considerations ................42 6.2.1. Connectivity .......................................43 6.2.2. Privacy ............................................43 6.2.3. Content Agnosticism ................................44 6.2.4. Security ...........................................45 6.2.5. Internationalization ...............................46 6.2.6. Censorship Resistance ..............................47 6.2.7. Open Standards .....................................48 6.2.8. Heterogeneity Support ..............................50 6.2.9. Anonymity ..........................................51 6.2.10. Pseudonymity ......................................51 6.2.11. Accessibility .....................................53 6.2.12. Localization ......................................53 6.2.13. Decentralization ..................................54 6.2.14. Reliability .......................................55 6.2.15. Confidentiality ...................................56 6.2.16. Integrity .........................................58 6.2.17. Authenticity ......................................59 6.2.18. Adaptability ......................................60 6.2.19. Outcome Transparency ..............................61 7. Security Considerations ........................................61 8. IANA Considerations ............................................61 9. Research Group Information .....................................62 10. Informative References ........................................62 Acknowledgements ..................................................80 Authors' Addresses ................................................81
1. Introduction
"There's a freedom about the Internet: As long as we accept the rules of sending packets around, we can send packets containing anything to anywhere." [Berners-Lee] "The Internet isn't value-neutral, and neither is the IETF." [RFC3935] The ever-growing interconnectedness of the Internet and society increases the impact of the Internet on the lives of individuals. Because of this, the design and development of the Internet infrastructure also have a growing impact on society. This has led to a broad recognition that human rights [UDHR] [ICCPR] [ICESCR] have a role in the development and management of the Internet [UNGA2013] [NETmundial]. It has also been argued that the Internet should be strengthened as an enabling environment for human rights [Brown]. This document aims to (1) expose the relationship between protocols and human rights, (2) propose possible guidelines to protect the Internet as an enabling environment for human rights in future protocol development, in a manner similar to the work done for privacy considerations [RFC6973], and (3) increase the awareness, in both the human rights community and the technical community, of the importance of the technical workings of the Internet and its impact on human rights. Document authors who want to apply this work to their own can go directly to Section 6 of this document. Open, secure, and reliable connectivity is necessary (although not sufficient) to exercise human rights such as freedom of expression and freedom of association [FOC], as defined in the Universal Declaration of Human Rights [UDHR]. The purpose of the Internet is to be a global network of networks that provides unfettered connectivity to all users, and for any content [RFC1958]. This objective of stimulating global connectivity contributes to the Internet's role as an enabler of human rights. The Internet has given people a platform to exchange opinions and gather information; it has enabled people of different backgrounds and genders to participate in the public debate; it has also allowed people to congregate and organize. Next to that, the strong commitment to security [RFC1984] [RFC3365] and privacy [RFC6973] [RFC7258] in the Internet's architectural design contributes to the strengthening of the Internet as an enabling environment for human rights. One could even argue that the Internet is not only an enabler of human rights but that human rights lie at the base of, and are ingrained in, the architecture of the networks that make up the Internet. Internet
connectivity increases the capacity for individuals to exercise their rights; the core of the Internet -- its architectural design -- is therefore closely intertwined with the human rights framework [CathFloridi]. The quintessential link between the Internet's infrastructure and human rights has been argued by many. [Bless1], for instance, argues that "to a certain extent, the Internet and its protocols have already facilitated the realization of human rights, e.g., the freedom of assembly and expression. In contrast, measures of censorship and pervasive surveillance violate fundamental human rights." [DeNardis15] argues that "Since the first hints of Internet commercialization and internationalization, the IETF has supported strong security in protocol design and has sometimes served as a force resisting protocol-enabled surveillance features." By doing so, the IETF enabled the manifestation of the right to privacy, through the Internet's infrastructure. Additionally, access to freely available information gives people access to knowledge that enables them to help satisfy other human rights; as such, the Internet increasingly becomes a precondition for human rights rather than a supplement. Human rights can be in conflict with each other, such as the right to freedom of expression and the right to privacy. In such cases, the different affected rights need to be balanced. To do this, it is crucial that the impacts on rights are clearly documented in order to mitigate potential harm. This research aims to ultimately contribute to making that process tangible and practical for protocol developers. Technology can never be fully equated with a human right. Whereas a specific technology might be a strong enabler of a specific human right, it might have an adverse impact on another human right. In this case, decisions on design and deployment need to take this into account. The open nature of the initial technical design and its open standards, as well as developments like open source, fostered freedom of communication. What emerged was a network of networks that could enable everyone to connect and to exchange data, information, and code. For many, enabling such connections became a core value. However, as the scale and the commercialization of the Internet grew, topics like access, rights, and connectivity have been forced to compete with other values. Therefore, important characteristics of the Internet that enable human rights might be degraded if they're not properly defined, described, and protected as such. Conversely, not protecting characteristics that enable human rights could also result in (partial) loss of functionality and connectivity, along with other inherent parts of the Internet's architecture of networks. New protocols, particularly those that upgrade the core infrastructure of the network, should be designed to continue to enable fundamental human rights.
The IETF has produced guidelines and procedures to ensure and galvanize the privacy of individuals and security of the network in protocol development. This document aims to explore the possibility of developing similar procedures for guidelines for human rights considerations to ensure that protocols developed in the IETF do not have an adverse impact on the realization of human rights on the Internet. By carefully considering the answers to the questions posed in Section 6 of this document, document authors should be (1) able to produce a comprehensive analysis that can serve as the basis for discussion on whether the protocol adequately protects against specific human rights threats and (2) potentially stimulated to think about alternative design choices. This document was developed within the framework of the Human Rights Protocol Considerations (HRPC) Research Group, based on discussions on the HRPC mailing list (Section 9); this document was also extensively discussed during HRPC sessions. This document has received eleven in-depth reviews on the mailing list, and it received many comments from inside and outside the IRTF and IETF communities.2. Vocabulary Used
In the discussion of human rights and Internet architecture, concepts developed in computer science, networking, law, policy-making, and advocacy are coming together [Dutton] [Kaye] [Franklin] [RFC1958]. The same concepts might have a very different meaning and implications in other areas of expertise. In order to foster a constructive interdisciplinary debate and minimize differences in interpretation, the following glossary is provided. It builds as much as possible on existing definitions; when definitions were not available in IETF documents, definitions were taken from other Standards Development Organizations (SDOs) or academic literature. Accessibility: "Full Internet Connectivity", as described in [RFC4084], to provide unfettered access to the Internet. The design of protocols, services, or implementations that provide an enabling environment for people with disabilities. The ability to receive information available on the Internet. Anonymity: The condition of an identity being unknown or concealed [RFC4949]. Anonymous: A state of an individual in which an observer or attacker cannot identify the individual within a set of other individuals (the anonymity set) [RFC6973].
Authenticity: The property of being genuine and able to be verified
and be trusted [RFC4949].
Blocking: The practice of preventing access to resources in the
aggregate [RFC7754]. Both blocking and filtering can be
implemented at the level of "services" (web hosting or video
streaming, for example) or at the level of particular "content"
[RFC7754].
Censorship: Technical mechanisms, including both blocking and
filtering, that certain political or private actors around the
world use to block or degrade Internet traffic. For further
details on the various elements of Internet censorship, see
[Hall].
Censorship resistance: Methods and measures to mitigate Internet
censorship.
Confidentiality: The property that data is not disclosed to system
entities unless they have been authorized to know the data
[RFC4949].
Connectivity: The extent to which a device or network is able to
reach other devices or networks to exchange data. The Internet is
the tool for providing global connectivity [RFC1958]. Different
types of connectivity are further specified in [RFC4084].
The end-to-end principle, interoperability, distributed
architecture, resilience, reliability, and robustness in
combination constitute the enabling factors that result in
connectivity to, and on, the Internet.
Content agnosticism: Treating network traffic identically regardless
of content.
Decentralized: Implementation or deployment of standards, protocols,
or systems without one single point of control.
End-to-end principle: The principle that application-specific
functions should not be embedded into the network and thus stay at
the endpoints. In many cases, especially when dealing with
failures, the right decisions can only be made with the
corresponding application-specific knowledge, which is available
at endpoints not in the network.
The end-to-end principle is one of the key architectural
guidelines of the Internet. The argument in favor of the
end-to-end approach to system design is laid out in the
fundamental papers by Saltzer, Reed, and Clark [Saltzer] [Clark].
In these papers, the authors argue in favor of radical
simplification: system designers should only build the essential
and shared functions into the network, as most functions can only
be implemented at network endpoints. Building features into the
network for the benefit of certain applications will come at the
expense of others. As such, in general system designers should
attempt to steer clear of building anything into the network that
is not a bare necessity for its functioning. Following the
end-to-end principle is crucial for innovation, as it makes
innovation at the edges possible without having to make changes to
the network, and it protects the robustness of the network.
[RFC2775] further elaborates on various aspects of end-to-end
connectivity.
Federation: The possibility of connecting autonomous and possibly
centralized systems into a single system without a central
authority.
Filtering: The practice of preventing access to specific resources
within an aggregate [RFC7754].
Heterogeneity: "The Internet is characterized by heterogeneity on
many levels: devices and nodes, router scheduling algorithms and
queue management mechanisms, routing protocols, levels of
multiplexing, protocol versions and implementations, underlying
link layers (e.g., point-to-point, multi-access links, wireless,
FDDI, etc.), in the traffic mix and in the levels of congestion at
different times and places. Moreover, as the Internet is composed
of autonomous organizations and internet service providers, each
with their own separate policy concerns, there is a large
heterogeneity of administrative domains and pricing structures."
[FIArch]
As a result, per [FIArch], the heterogeneity principle proposed in
[RFC1958] needs to be supported by design.
Human rights: Principles and norms that are indivisible,
interrelated, unalienable, universal, and mutually reinforcing.
Human rights have been codified in national and international
bodies of law. The Universal Declaration of Human Rights [UDHR]
is the most well-known document in the history of human rights.
The aspirations from [UDHR] were later codified into treaties such
as the International Covenant on Civil and Political Rights
[ICCPR] and the International Covenant on Economic, Social and
Cultural Rights [ICESCR], after which signatory countries were
obliged to reflect them in their national bodies of law. There is
also a broad recognition that not only states have obligations
vis-a-vis human rights, but non-state actors do as well.
Integrity: The property that data has not been changed, destroyed,
or lost in an unauthorized or accidental manner [RFC4949].
Internationalization (i18n): The practice of making protocols,
standards, and implementations usable in different languages and
scripts (see Section 6.2.12 ("Localization")).
"In the IETF, 'internationalization' means to add or improve the
handling of non-ASCII text in a protocol" [RFC6365].
A different perspective, more appropriate to protocols that are
designed for global use from the beginning, is the definition used
by the World Wide Web Consortium (W3C) [W3Ci18nDef]:
"Internationalization is the design and development of a product,
application or document content that enables easy localization for
target audiences that vary in culture, region, or language."
Many protocols that handle text only handle one charset
(US-ASCII), or they leave the question of encoding up to local
guesswork (which leads, of course, to interoperability problems)
[RFC3536]. If multiple charsets are permitted, they must be
explicitly identified [RFC2277]. Adding non-ASCII text to a
protocol allows the protocol to handle more scripts, hopefully all
scripts in use in the world. In today's world, that is normally
best accomplished by allowing Unicode encoded in UTF-8 only,
thereby shifting conversion issues away from ad hoc choices.
Interoperable: A property of a documented standard or protocol that
allows different independent implementations to work with each
other without any restriction on functionality.
Localization (l10n): The practice of translating an implementation
to make it functional in a specific language or for users in a
specific locale (see Section 6.2.5 ("Internationalization")).
(cf. [RFC6365]): The process of adapting an internationalized
application platform or application to a specific cultural
environment. In localization, the same semantics are preserved
while the syntax may be changed [FRAMEWORK].
Localization is the act of tailoring an application for a
different language, script, or culture. Some internationalized
applications can handle a wide variety of languages. Typical
users only understand a small number of languages, so the program
must be tailored to interact with users in just the languages they
know. The major work of localization is translating the user
interface and documentation. Localization involves not only
changing the language interaction but also other relevant changes,
such as display of numbers, dates, currency, and so on. The
better internationalized an application is, the easier it is to
localize it for a particular language and character-encoding
scheme.
Open standards: Conform with [RFC2026], which states the following:
"Various national and international standards bodies, such as
ANSI, ISO, IEEE, and ITU-T, develop a variety of protocol and
service specifications that are similar to Technical
Specifications defined here. National and international groups
also publish 'implementors' agreements' that are analogous to
Applicability Statements, capturing a body of implementation-
specific detail concerned with the practical application of their
standards. All of these are considered to be 'open external
standards' for the purposes of the Internet Standards Process."
Openness: Absence of centralized points of control -- "a feature
that is assumed to make it easy for new users to join and new uses
to unfold" [Brown].
Permissionless innovation: The freedom and ability to freely create
and deploy new protocols on top of the communications constructs
that currently exist.
Privacy: The right of an entity (normally a person), acting on its
own behalf, to determine the degree to which it will interact with
its environment, including the degree to which the entity is
willing to share its personal information with others [RFC4949].
The right of individuals to control or influence what information
related to them may be collected and stored, and by whom and to
whom that information may be disclosed.
Privacy is a broad concept relating to the protection of
individual or group autonomy and the relationship between an
individual or group and society, including government, companies,
and private individuals. It is often summarized as "the right to
be left alone", but it encompasses a wide range of rights,
including protections from intrusions into family and home life,
control of sexual and reproductive rights, and communications
secrecy. It is commonly recognized as a core right that underpins
human dignity and other values such as freedom of association and
freedom of speech.
The right to privacy is also recognized in nearly every national
constitution and in most international human rights treaties. It
has been adjudicated upon by both international and regional
bodies. The right to privacy is also legally protected at the
national level through provisions in civil and/or criminal codes.
Reliability: Ensures that a protocol will execute its function
consistently as described and function without unexpected results.
A system that is reliable degenerates gracefully and will have a
documented way to announce degradation. It also has mechanisms to
recover from failure gracefully and, if applicable, allow for
partial healing [dict].
Resilience: The maintaining of dependability and performance in the
face of unanticipated changes and circumstances [Meyer].
Robustness: The resistance of protocols and their implementations to
errors, and resistance to involuntary, legal, or malicious
attempts to disrupt their modes of operation [RFC760] [RFC791]
[RFC793] [RFC1122]. Or, framed more positively, a system can
provide functionality consistently and without errors despite
involuntary, legal, or malicious attempts to disrupt its mode of
operation.
Scalability: The ability to handle increased or decreased system
parameters (number of end systems, users, data flows, routing
entries, etc.) predictably within defined expectations. There
should be a clear definition of its scope and applicability. The
limits of a system's scalability should be defined. Growth or
shrinkage of these parameters is typically considered by orders of
magnitude.
Strong encryption / cryptography: Used to describe a cryptographic
algorithm that would require a large amount of computational power
to defeat it [RFC4949]. In the modern usage of the definition of
"strong encryption", this refers to an amount of computing power
currently not available, not even to major state-level actors.
Transparency: In this context, linked to the comprehensibility of a
protocol in relation to the choices it makes for users, protocol
developers, and implementers, and to its outcome.
Outcome transparency is linked to the comprehensibility of the
effects of a protocol in relation to the choices it makes for
users, protocol developers, and implementers, including the
comprehensibility of possible unintended consequences of protocol
choices (e.g., lack of authenticity may lead to lack of integrity
and negative externalities).
3. Research Questions
The Human Rights Protocol Considerations (HRPC) Research Group in the Internet Research Task Force (IRTF) embarked on its mission to answer the following two questions, which are also the main two questions that this document seeks to answer: 1. How can Internet protocols and standards impact human rights, by either enabling them or creating a restrictive environment? 2. Can guidelines be developed to improve informed and transparent decision-making about the potential impact of protocols on human rights?4. Literature and Discussion Review
Protocols and standards are regularly seen as merely performing technical functions. However, these protocols and standards do not exist outside of their technical context, nor do they exist outside of their political, historical, economic, legal, or cultural context. This is best exemplified by the way in which some Internet processes and protocols have become part and parcel of political processes and public policies: one only has to look at the IANA transition, [RFC7258] ("Pervasive Monitoring Is an Attack"), or global innovation policy, for concrete examples [DeNardis15]. According to [Abbate], "protocols are politics by other means." This statement would probably not garner IETF consensus, but it nonetheless reveals that protocols are based on decision-making, most often by humans. In this process, the values and ideas about the role that a particular technology should perform in society are embedded into the design. Often, these design decisions are partly "purely technical" and partly inspired by a certain world view of how technology should function that is inspired by personal, corporate, and political views. Within the community of IETF participants, there is a strong desire to solve technical problems and to minimize engagement with political processes and non-protocol-related political issues. Since the late 1990s, a burgeoning group of academics and practitioners researched questions surrounding the societal impact of protocols, as well as the politics of protocols. These studies vary in focus and scope: some focus on specific standards [Davidson-etal] [Musiani]; others look into the political, legal, commercial, or social impact of protocols [BrownMarsden] [Lessig] [Mueller]; and yet others look at how the engineers' personal set of values get translated into technology [Abbate] [CathFloridi] [DeNardis15] [WynsbergheMoura].
Commercial and political influences on the management of the Internet's infrastructure are well documented in the academic literature and will thus not be discussed here; see [Benkler], [Brown-etal], [DeNardis15], [Lessig], [Mueller], and [Zittrain]. It is sufficient to say that the IETF community consistently tries to push back against the standardization of surveillance and certain other issues that negatively influence an end user's experience of, and trust in, the Internet [DeNardis14]. The role that human rights play in engineering, infrastructure maintenance, and protocol design is much less clear. It is very important to understand how protocols and standards impact human rights, in particular because SDOs are increasingly becoming venues where social values (like human rights) are discussed, although often from a technological point of view. These SDOs are becoming a new focal point for discussions about "values by design" and the role of technical engineers in protecting or enabling human rights [Brown-etal] [Clark-etal] [DeNardis14] [CathFloridi] [Lessig] [Rachovitsa]. In the academic literature, five clear positions can be discerned in relation to the role of human rights in protocol design and how to account for these human rights in protocol development: Clark et al. [Clark-etal] argue that there is a need to design "for variation in outcome -- so that the outcome can be different in different places, and the tussle takes place within the design (...)" [as] "Rigid designs will be broken; designs that permit variation will flex under pressure and survive." They hold that human rights should not be hard-coded into protocols for three reasons: First, the rights in the UDHR are not absolute. Second, technology is not the only tool in the tussle over human rights. And last but not least, it is dangerous to make promises that can't be kept. The open nature of the Internet will never, they argue, be enough to fully protect individuals' human rights. Conversely, Brown et al. [Brown-etal] state that "some key, universal values -- of which the UDHR is the most legitimate expression -- should be baked into the architecture at design time." They argue that design choices have offline consequences and are able to shape the power positions of groups or individuals in society. As such, the individuals making these technical decisions have a moral obligation to take into account the impact of their decisions on society and, by extension, human rights. Brown et al. recognize that values and the implementation of human rights vary across the globe. Yet they argue that all members of the United Nations have found "common agreement on the values proclaimed in the Universal Declaration of Human Rights. In looking for the most legitimate set
of global values to embed in the future Internet architectures, the UDHR has the democratic assent of a significant fraction of the planet's population, through their elected representatives." The main disagreement between these two academic positions lies mostly in the question of whether (1) a particular value system should be embedded into the Internet's architectures or (2) the architectures need to account for a varying set of values. A third position, which is similar to that of Brown et al., is taken by [Broeders], in which Broeders argues that "we must find ways to continue guaranteeing the overall integrity and functionality of the public core of the Internet." He argues that the best way to do this is by declaring the backbone of the Internet -- which includes the TCP/IP protocol suite, numerous standards, the Domain Name System (DNS), and routing protocols -- a common public good. This is a different approach than those of [Clark-etal] and [Brown-etal] because Broeders does not suggest that social values should (or should not) be explicitly coded into the Internet, but rather that the existing infrastructure should be seen as an entity of public value. Bless and Orwat [Bless2] represent a fourth position. They argue that it is too early to make any definitive claims but that there is a need for more careful analysis of the impact of protocol design choices on human rights. They also argue that it is important to search for solutions that "create awareness in the technical community about impact of design choices on social values" and "work towards a methodology for co-design of technical and institutional systems." Berners-Lee and Halpin [BernersLeeHalpin] represent a fifth position. They argue that the Internet could lead to even newer capacities, and these capacities may over time be viewed as new kinds of rights. For example, Internet access may be viewed as a human right in and of itself if it is taken to be a precondition for other rights, even if it could not have been predicted at the time that the UDHR was written (after the end of World War II). It is important to contextualize the technical discussion with the academic discussions on this issue. The academic discussions are also important to document, as they inform the position of the authors of this document. The research group's position is that hard-coding human rights into protocols is complicated and changes with the context. At this point, it is difficult to say whether or not hard-coding human rights into protocols is wise or feasible. Additionally, there are many human rights, but not all are relevant for information and communications technologies (ICTs). A partial
catalog (with references to sources) of human rights related to ICTs can be found in [Hill2014]. It is, however, important to make conscious and explicit design decisions that take into account the human rights protocol considerations guidelines developed below. This will contribute to the understanding of the impact that protocols can have on human rights, for both developers and users. In addition, it contributes to (1) the careful consideration of the impact that a specific protocol might have on human rights and (2) the dissemination of the practice of documenting protocol design decisions related to human rights. Pursuant to the principle of constant change, because the function and scope of the Internet evolve, so does the role of the IETF in developing standards. Internet Standards are adopted based on a series of criteria, including high technical quality, support by community consensus, and their overall benefit to the Internet. The latter calls for an assessment of the interests of all affected parties and the specifications' impact on the Internet's users. In this respect, the effective exercise of the human rights of the Internet users is a relevant consideration that needs to be appreciated in the standardization process insofar as it is directly linked to the reliability and core values of the Internet [RFC1958] [RFC2775] [RFC3439] [RFC3724]. This document details the steps taken in the research into human rights protocol considerations by the HRPC Research Group to clarify the relationship between technical concepts used in the IETF and human rights. This document sets out some preliminary steps and considerations for engineers to take into account when developing standards and protocols.
(page 15 continued on part 2)
