Research into Human Rights Protocol Considera= tions

Mapping the relation between human rights, protocols and architectures= is a new research challenge, which requires a good amount of interdiscip= linary and cross organizational cooperation to develop a consistent metho= dology.=C2=A0 The authors of this first draft are involved in=C2=A0both h= uman rights advocacy and research on Internet technologies - and as such = believe that bringing this work into the IRTF facilitates and=C2=A0 impr= oves it by bringing human rights experts together with the community of r= esearchers and developers of Internet standards and technologies. The methodological choices made in this document are based on the poli= tical science-based method of discourse analysis and ethnographic researc= h methods . This work departs from the assumption = that language reflects the understanding of concepts. Or as holds, policy documents are =E2=80=98social relations represent= ed in texts where language is used to construct meaning and representatio= n=E2=80=99. This process happens in =E2=80=98the social space of society=E2= =80=99 and manifests itself in institutions = and organizations , exposed using the ethnographic= methods of semi-structured interviews and participant observation. The discourse analysis was operationalized using qualitative and quant= itative means. The first step taken by the research group was reading RF= Cs and other official IETF documents. The second step was the use of a py= hon-based analyzer, using the tool Big Bang, adapted by Nick Doty to scan for the concepts that were identified as importa= nt architectural principles (distilled on the initial reading and supplem= ented by the interviews and participant observation). Such a quantitative= method is very precise and speeds up the research process . But this tool is unable to understand =E2=80=98latent meaning= =E2=80=99 . In order to mitigate these issues of= automated word-frequency based approaches, and to get a sense of the =E2= =80=98thick meaning=E2=80=99 of the data, a sec= ond qualitative analysis of the data set was performed. These various rou= nds of discourse analysis were used to inform the interviews and further = data analysis. The ethnographic methods of the data collection and processing allowed= the research group to acquire the data necessary to =E2=80=98provide a h= olistic understanding of research participants=E2=80=99 views and actions= =E2=80=99 that highlighted ongoing issues and c= ase studies where protocols impact human rights. The interview participan= ts were selected through purposive sampling , as= the research group was interested in getting a wide variety of opinions = on the role of human rights in guiding protocol development. This samplin= g method also ensured that individuals with extensive experience working = at the IETF in various roles were targeted. The interviewees included ind= ividuals in leadership positions (Working Group (WG) chairs, Area Directo= rs (ADs)), =E2=80=98regular participants=E2=80=99, individuals working fo= r specific entities (corporate, civil society, political, academic) and r= epresented various backgrounds, nationalities and genders.

In order to map the potential relation between human rights and protoc= ols, so far, the HRPC research group gathered data from three specific so= urces:=E2=80=A8

To start addressing the issue, a mapping exercise analyzing Internet a= rchitecture and protocols features, vis-a-vis their possible impact on hu= man rights was undertaken. Therefore, research on the language used in cu= rrent and historic RFCs and mailing list discussions was undertaken to ex= pose core architectural principles, language and deliberations on human r= ights of those affected by the network.

Interviews with the current and past members of the Internet Architect= ure Board (IAB), current and past members of the Internet Engineering Ste= ering Group (IESG) and chairs of selected working groups and RFC authors = was done at the Dallas meeting in March 2015. To get an insider understan= ding of how they view the relationship (if any) between human rights and = protocols to play out in their work.

By participating in various working groups, in person at IETF meetings= and on mailinglists, information was gathered about the IETFs day-to-day= workings. From which which general themes, technical concepts, and use-c= ases about human rights and protocols were extracted.

The data above was processed using three consecutive strategies: mappi= ng protocols related to human rights, extracting concepts from these prot= ocols, and creation of a common glossary (detailed under =E2=80=9C2.vocab= ulary used=E2=80=9D). Before going over these strategies some elaboration= on the process of identifying technical concepts as they relate to human= rights needs to be given:=C2=A0

By combining data from the three data sources named above, an extensiv= e list of=C2=A0 protocols and standards that potentially enable the Inter= net as a tool for freedom of expression and association was assembly. In = order to determine the enabling (or inhibiting) features we relied on dir= ect references of such impact in the RFCs, as well as input from the comm= unity. On the basis of this analysis a list of RFCs that describe standar= ds and protocols that are potentially closely related to human rights was= compiled.

Mapping the protocols and standards that are related to human rights a= nd create a human rights enabeling environment was the first step. For th= at we needed to focus on specific technical concepts that underlie these = protocols and=C2=A0 standards. On the basis of this list a number of tech= nical concepts that appeared frequently was extracted, and used to create= a second list of technical terms that, when combined, create an enabling= environment for excercising human rights on the Internet.=C2=A0

While interviewing experts, mapping RFCs and compiling technical defin= itions several concepts of convergence and divergence were identified. To= ensure that the discussion was based on a common understanding of terms = and vocabulary, a list of definitions was created. The definitions are ba= sed on the wording found in various IETF documents, and if these were una= vailable definitions were taken from definitions from other Standards Dev= eloping Organizations or academic literature.

The previous steps allowed for the clarification of relation between h= uman rights and technical concepts. The steps taken show how the research= process zoomed in, from compiling a broad lists of protocols and standar= ds that relate to human rights to extracting the precise technical concep= ts that make up these protocols and standards, in order to understand the= relationship between the two. This sub-section presents the next step: t= ranslating human rights to technical concepts by matching the individuals= components of the rights to the accompanying technical concepts, allowin= g for the creation of a list of technical concepts that when combined cre= ate an enabling environment for human rights.

On the basis of the prior steps the following list of technical term= s, that when combined create an enabling environment for human rights, su= ch a freedom of expression and freedom of association, was drafted.

This analysis aims to translate human rights concepts that impact or a= re impacted by the Internet as follows: The combination of content agnosticism, connectivity, security, privac= y (as defined in ), and open standards are the= technical principles that underlie freedom of expression on the Internet= =2E

Given the information above, the following list of cases of protocols = that adversely impact or enable human rights was formed.

The Internet Protocol version 4 (IPv4), also known as =E2=80=98layer 3= =E2=80=99 of the Internet, and specified as a common encapsulation and pr= otocol header, is defined in . The evolution of= Internet communications led to continued development in this area, encap= sulated in the development of version 6 (IPv6) of the protocol in . In spite of this updated protocol, we find that 25 y= ears after the specification of version 6 of the protocol, the older v4 s= tandard continues to account for a sizeable majority of Internet traffic,= and most (if not all) of the issues discussed here are valid for IPv4 as= well as IPv6. The Internet was designed as a platform for free and open communicatio= n, most notably encoded in the end-to-end principle, and that philosophy = is also present in the technical implementation of the Internet Protocol.= While the protocol was designed to exist in a= n environment where intelligence is at the end hosts, it has proven to pr= ovide sufficient information that a more intelligent network core can mak= e policy decisions and enforce policy shaping and restricting the communi= cations of end hosts. These capabilities for network control and limitati= ons of the freedom of expression by end hosts can be traced back to the I= Pv4 design, helping us understand which technical protocol decisions have= led to harm of these human rights. Two major shifts have occurred to harm freedom of expression through m= isuse of the Internet Protocol. The first is the network=E2=80=99s exploi= tation of the public visibility of the host pairs for all communications,= and the corresponding ability to discriminate and block traffic as a res= ult of that metadata. The second is the selective development of IP optio= ns. Protocol extensions including Mobility and Multicasting have proposed= alternate communication modes and suggest that different forms of assemb= ly could be supported by a robust IP layer. Instead, the protocol limited= the deployability of such extensions by not providing a mechanism for ap= propriate fallback behavior when unrecognized extensions are encountered.=

The IPv4 protocol header contains fixed location fields for both the s= ource and destination IP addresses . These addr= esses identify both the host sending and receiving each message, and allo= w the core network to understand who is talking to whom, and to practical= ly limit communication selectively between pairs of hosts. Blocking of co= mmunication based on the pair of source and destination is one of the mos= t common limitations on the ability for hosts to communicate today, and can be seen as a restriction of the ability for t= hose hosts to assemble or to consensually express themselves. Inclusion of an Internet-wide identified source in the IP header is no= t the only possible design, especially since the protocol is most commonl= y implemented over Ethernet networks exposing only link-local identifiers= =2E A variety of alternative designs including= source routing, which would allow for the sender to choose a per defined= (safe) route, and spoofing of the source IP address are technically supp= orted by the protocol, but neither are considered good practice on the In= ternet. While projects like provide an alte= rnative implementation of anonymity in connections, they have been develo= ped in spite of the IPv4 protocol design.

The other major feature of the IP protocol header is that it specifies= the protocol encapsulated in each message in an easily observable form, = and does not encourage a design where the encapsulated protocol is not av= ailable to a network observer. This design has resulted in a proliferatio= n of routers which inspect the inner protocol, and also led to a stagnati= on where only the TCP and UDP protocols are widely supported across the I= nternet. While the IP protocol was designed as the entire set of metadata= needed for routing, subsequent enhanced routers have found value on maki= ng policy decisions based on the contents of TCP and UDP headers as well,= and are encoded with the assumption that only these protocols will be us= ed for data transfer. = defines an encrypted encapsulation of additional protocols, but lacks wid= espread deployment and faces the same challenge as any other protocol of = providing sufficient metadata with each message for routers to make posit= ive policy decisions. Protocols like have seen= limited wide-area uptake, and these alternate designs are frequently re-= implemented on top of UDP.

A major structural shift in the Internet which undermined the protocol= design of IPv4, and significantly reduced the freedom of end users to co= mmunicate and assemble is the introduction of network address translation= =2E Network address translation is a process w= hereby organizations and autonomous systems connect two networks by trans= lating the IPv4 source and destination addresses between the two. This pr= ocess puts the router performing the translation into a privileged positi= on, where it can decide which subset of communications are worthy of tran= slation, and whether an unknown request for communication will be correct= ly forwarded to a host on the other network. This process of translation has widespread adoption despite promoting = a process that goes against the stated end-to-end process of the underlyi= ng protocol . In contrast, the proposed mechan= ism to provide support for mobility and forwarding to clients which may m= ove, encoded instead as an option in the IP protocol in , has failed to gain traction. In this situation the compromise = made in the design of the protocol resulted in a technology that does not= fully encode freedom of expression in its design, eventhough a viable al= ternative that would do this exists.

The Domain Name System (DNS) , provides serv= ice discovery capabilities, and provides a mechanism to associate human r= eadable names with services. The DNS system is organized around a set of = independently operated =E2=80=98Root Servers=E2=80=99 run by organization= s around the web which enact ICANN=E2=80=99s policy by answering queries = for which organizations have been delegated to manage registration under = each Top Level Domain (TLD). Top Level domains are maintained and determi= ned by ICANN. These namespaces encompass several classes of services. The= initial name spaces including =E2=80=98.Com=E2=80=99 and =E2=80=98.Net=E2= =80=99, provide common spaces for expression of ideas, though their polic= ies are enacted through US based companies. Other name spaces are delegat= ed to specific nationalities, and may impose limits designed to focus spe= ech in those forums both to promote speech from that nationality, and to = comply with local limits on expression and social norms. Finally, the sys= tem has recently been expanded with additional generic and sponsored name= spaces, for instance =E2=80=98.travel=E2=80=99 and =E2=80=98.ninja=E2=80= =99, which are operated by a range of organizations which may independent= ly determine their registration policies. This new development has both p= ositive and negative implications in terms of enabling human rights. Some= individuals argue that it undermines the right to freedom of expression = because some of these new gtlds have restricted policies on registration = and particular rules on hate speech content. Others argue that precisely = these properties are positive because they enable certain (mostly minorit= y) communities to build safer spaces for association, thereby enabling th= eir right to freedom of association. An often mentioned example is an app= lication like .gay. DNS has significant privacy issues per . Mos= t notable the lack of encryption to limit the visibility of requests for = domain resolution from intermediary parties, and a limited deployment of = DNSSEC to provide authentication, allowing the client to know that they r= eceived a correct, =E2=80=9Cauthoritative=E2=80=9D, answer to a query. Authentication through DNSSEC creates a validation path for records. T= his authentication protects against forged or manipulated DNS data. As su= ch DNSSEC protects the directory look-up and makes hijacking of a session= harder. This is important because currently interference with the operat= ion of the DNS is becoming one of the central mechanisms used to block ac= cess to websites. This interference limits both the freedom of expression= of the publisher to offer their content, and the freedom of assembly for= clients to congregate in a shared virtual space. Even though DNSSEC does= n=E2=80=99t prevent censorship, it makes it clear that the returned infor= mation is not the information that was requested, which contributes to th= e right to security and increases trust in the network.

There have been a number of cases where the records for a domain are r= emoved from the name system due to real-world events. Examples of this re= moval includes the =E2=80=98seizure=E2=80=99 of wikileaks and the names of illegally operating gambling operation= s by the United States ICE unit, which compelled the US-based registry in= charge of the .com TLD to hand ownership of those domains over to the US= government. The same technique has been used in Libya to remove sites in= violation of =E2=80=9Cour Country=E2=80=99s Law and Morality (which) do = not allow any kind of pornography or its promotion.=E2=80=9D At a protocol level, there is no technical auditing for name ownership= , as in alternate systems like . As a result, = there is no ability for users to differentiate seizure from the legitimat= e transfer of name ownership, which is purely a policy decision of regist= rars. While DNSSEC addresses network distortion events described below, i= t does not tackle this problem.

The most common mechanism by which the DNS system is abused to limit f= reedom of expression is through manipulation of protocol messages by the = network. One form occurs at an organizational level, where client compute= rs are instructed to use a local DNS resolver controlled by the organizat= ion. The DNS resolver will then selectively distort responses rather than= request the authoritative lookup from the upstream system. The second fo= rm occurs through the use of deep packet inspection, where all DNS protoc= ol messages are inspected by the network, and objectionable content is di= storted, as in . A notable instance of distortion occurred in Greece , where a study found evidence of both of deep packet inspection= to distort DNS replies, and overblocking of content. ISPs prevented clie= nts from resolving the names of domains which they were instructed to do = through a governmental order, prompting this particular blocking systems = there. At a protocol level, the effectiveness of these attacks is made possib= le by a lack of authentication in the DNS protocol. DNSSEC provides the a= bility to determine authenticity of responses when used, but it is not re= gularly checked by resolvers. DNSSEC is not effective when the local reso= lver for a network is complicit in the distortion, for instance when the = resolver assigned for use by an ISP is the source of injection. Selective= distortion of records is also been made possible by the predictable stru= cture of DNS messages, which make it computationally easy for a network d= evice to watch all passing messages even at high speeds, and the lack of = encryption, which allows the network to distort only an objectionable sub= set of protocol messages. Specific distortion mechanisms are discussed fu= rther in .

Responding incorrectly to requests for name lookups is the most common= mechanism that in-network devices use to limit the ability of end users = to discover services. A deviation, which accomplishes a similar objective= may be seen as different from a freedom of expression perspective, is th= e injection of incorrect responses to queries. The most prominent example= of this behavior occurs in China, where requests for lookups of sites de= emed inappropriate will trigger the network to respond with a false response, causing the client to ignore the real response when it subseque= ntly arrives. Unlike the other forms of = discussion mentioned above, injection does not stifle the ability of a se= rver to announce it=E2=80=99s name, it instead provides another voice whi= ch answers sooner. This is effective because without DNSSEC, the protocol= will respond to whichever answer is received first, without listening fo= r subsequent answers.

The Hypertext Transfer Protocol (HTTP), described in its version 1.1 i= n RFC 7230 to 7237, is a request-response application protocol developed = throughout the 1990s, and factually contributed to the exponential growth= of the Internet and the inter-connection of populations around the world= =2E Because of its simple design, HTTP has become the foundation of most = modern Internet platforms and communication systems, from websites, to ch= at systems, and computer-to-computer applications. In its manifestation w= ith the World Wide Web, HTTP radically revolutionized the course of techn= ological development and the ways people interact with online content and= with each other. However, HTTP is also a fundamentally insecure protocol, that doesn=E2= =80=99t natively provide encryption properties. While the definition of t= he Secure Sockets Layer (SSL), and later of Transport Layer Security (TLS= ), also happened during the 1990s, the fact that HTTP doesn=E2=80=99t man= date the use of such encryption layers to developers and service provider= s, caused a very late adoption of encryption. Only in the middle of the 2= 000s did we observed big Internet service providers, such as Google, star= ting to provide encrypted access to their web services. The lack of sensitivity and understanding of the critical importance o= f securing web traffic incentivized malicious and offensive actors to dev= elop, deploy and utilize at large interception systems and later active i= njection attacks, in order to swipe large amounts of data, compromise Int= ernet-enabled devices. The commercial availability of systems and tools t= o perform these types of attacks also led to a number of human rights abu= ses that have been discovered and reported over the years. Generally we can identify in Traffic Interception and Traffic Manipula= tion the two most problematic attacks that can be performed against appli= cations employing a clear-text HTTP transport layer. That being said, the= IETF and especially the General Area Review Team (Gen-ART), is taking st= eady steps to move to the encrypted version of HTTP, HTTPSecure (HTTPS).<= /t>

While we are seeing an increasing trend in the last couple of years to= employ SSL/TLS as a secure traffic layer for HTTP-based applications, we= are still far from seeing an ubiquitous use of encryption on the World W= ide Web. It is important to consider that the adoption of SSL/TLS is also= a relatively recent phenomena. Google introduced an option for its GMail= users to navigate with SSL only in 2008 , and = turned SSL on by default later in 2010 . It t= ook an increasing amount of security breaches and revelations on global s= urveillance from Edward Snowden to have other Internet service providers = to follow Google=E2=80=99s lead. For example, Yahoo enabled SSL/TLS by de= fault on its webmail services only towards the end of 2013 . As we learned through the Snowden=E2=80=99s revelations, intelligence = agencies have been intercepting and collecting unencrypted traffic at lar= ge for many years. There are documented examples of such mass surveillanc= e programs with GCHQ=E2=80=99s TEMPORA and NSA=E2=80=99s XKEYSCORE. Throu= gh these programs NSA/GCHQ have been able to swipe large amounts of data = including email and instant messaging communications which have been tran= sported by the respective providers in clear for years, unsuspecting of t= he pervasiveness and scale of governments=E2=80=99 efforts and investment= into global mass surveillance capabilities. However, similar mass interception of unencrypted HTTP communications = is also often employed at a nation-level by less democratic countries by = exercising control over state-owned Internet Service Providers (ISP) and = through the use of commercially available monitoring, collection, and cen= sorship equipment. Over the last few years a lot of information has come = to public attention on the role and scale of a surveillance industry dedi= cated to develop interception gear of different types, making use of know= n and unknown weaknesses in existing protocols = =2E We have several records of such equipment being sold and utilized by = oppressive regimes in order to monitor entire segments of population espe= cially at times of social and political distress, uncovering massive huma= n rights abuses. For example, in 2013 the group Telecomix revealed that t= he Syrian regime was making use of BlueCoat products in order to intercep= t clear-text traffic as well as to enforce censorship of unwanted content= . Similarly in 2012 it was found that the French A= mesys provided the Gaddafi=E2=80=99s government with equipment able to in= tercept emails, Facebook traffic, and chat messages ad a country level. T= he use of such systems, especially in the context of the Arab Spring and = of civil uprisings against the dictatorships, has caused serious concerns= of significant human rights abuses in Libya.

The lack of a secure transport layer over HTTP connections not only ex= poses the users to interception of the content of their communications, b= ut is more and more commonly abused as a vehicle for active compromises o= f computers and mobile devices. If an HTTP session travels in clear over = the network, any node positioned at any point in the network is able to p= erform man-in-the-middle attacks and observe, manipulate, and hijack the = session and modify the content of the communication in order to trigger u= nexpected behavior by the application generating the traffic. For example, in the case of a browser the attacke= r would be able to inject malicious code in order to exploit vulnerabilit= ies in the browser or any of its plugins. Similarly, the attacker would b= e able to intercept, trojanize, and repackage binary software updates tha= t are very commonly downloaded in clear by applications such as word proc= essors and media players. If the HTTP session would be encrypted, the tam= pering of the content would not be possible, and these network injection = attacks would not be successful. While traffic manipulation attacks have been long known, documented, a= nd prototyped especially in the context of WiFi and LAN networks, in the = last few years we observed an increasing investment into the production a= nd sale of network injection equipment both available commercially as wel= l as deployed at scale by intelligence agencies. For example we learned from some of the documents provided by Edward S= nowden to the press, that the NSA has constructed a global network inject= ion infrastructure, called QUANTUM, able to leverage mass surveillance in= order to identify targets of interests and subsequently task man-on-the-= side attacks to ultimately compromise a selected device. Among other atta= cks, NSA makes use of an attack called QUANTUMINSERT which intercepts and hijacks an unencrypted HTTP communication and= forces the requesting browser to redirect to a host controlled by NSA in= stead of the intended website. Normally, the new destination would be an = exploitation service, referred in Snowden documents as FOXACID, which wou= ld attempt at executing malicious code in the context of the target=E2=80= =99s browser. The Guardian reported in 2013 that NSA has for example been= using these techniques to target users of the popular anonymity service = Tor . The German NDR reported in 2014 that NSA= has also been using its mass surveillance capabilities to identify Tor u= sers at large . Recently similar capabilities of Chinese authorities have been reporte= d as well in what has been informally called the =E2=80=9CGreat Cannon=E2= =80=9D , which raised numerous concerns on the p= otential curb on human rights and freedom of speech due to the increasing= tighter control of Chinese Internet communications and access to informa= tion. Network injection attacks are also made widely available to state acto= rs around the world through the commercialization of similar, smaller sca= le equipment that can be easily acquired and deployed at a country-wide l= evel. Companies like FinFisher and HackingTeam are known to have network = injection gear within their products portfolio, respectively called FinFl= y ISP and RCS Network Injector . The tech= nology devised and produced by HackingTeam to perform network traffic man= ipulation attacks on HTTP communications is even the subject of a patent = application in the United States . Access = to offensive technologies available on the commercial lawful interception= market has been largely documented to have lead to human rights abuses a= nd illegitimate surveillance of journalists, human rights defenders, and = political activists in many countries around the world. Companies like Fi= nFisher and HackingTeam have been found selling their products to oppress= ive regimes with little concern for bad human rights records . While network injection attacks haven=E2=80=99t been the = subject of much attention, they do enable even unskilled attackers to per= form silent and very resilient compromises, and unencrypted HTTP remains = one of the main vehicles. There is a new version of HTTP, called HTTP/2, which was published as = and which aimed to be largely backwards compat= ible but also offer new option such as data compression of HTTP headers a= nd pipelining of request and multiplexing multiple requests over a single= TCP connection. Except for decreasing latency to improve page loading sp= eeds it also facilitates more efficient use of connectivity in low-bandwi= th environments, which is an enabler for freedom of expression, the right= to assembly, right to political participation and the right to participa= te in cultural life, art and science.=20 does not mandate Transport Layer Security or a= ny other form of encryption, is also does not support opportunistic encry= ption, so the vulnerabilities listed above for HTTP/1 are also valid for = HTTP/2 as defined in .

The Extensible Messaging and Presence Protocol (XMPP), specified in , provides a standard for interactive chat messag= ing, and has evolved to encompass interoperable text, voice, and video ch= at. The protocol is structured as a federated network of servers, similar= to email, where users register with a local server which acts one their = behalf to cache and relay messages. This protocol design has many advanta= ges, allowing servers to shield clients from denial of service and other = forms of retribution for their expression, and designed to avoid central = entities which could control the ability to communicate or assemble using= the protocol. None-the-less, there are plenty of aspects of the protocol design of X= MPP which shape the ability for users to communicate freely, and to assem= bly through the protocol. The protocol also has facets that may stifle sp= eech as users self-censor for fear of surveillance, or find themselves un= able to express themselves freely.

The XMPP specification dictates that clients are identified with a res= ource (node@domain/home /= node@domain/work) to dis= tinguish the conversations to specific devices. While the protocol does n= ot specify that the resource must be exposed by the client=E2=80=99s serv= er to remote users, in practice this has become the default behavior. In = doing so, users can be tracked by remote friends and their servers, who a= re able to monitor presence not just of the user, but of each individual = device the user logs in with. This has proven to be misleading to many us= ers, since many clients only expose user level = rather than device level presence. Likewise, user invisibility so that co= mmunication can occur while users don=E2=80=99t notify all buddies and ot= her servers of their availability is not part of the formal protocol, and= has only been added as an extension within the XML stream rather than en= forced by the protocol.

The XMPP protocol specifies the standard by which communication of cha= nnels may be encrypted, but it does not provide visibility to clients of = whether their communications are encrypted on each link. In particular, e= ven when both clients ensure that they have an encrypted connection to th= eir XMPP server to ensure that their local network is unable to read or d= isrupt the messages they send, the protocol does not provide visibility i= nto the encryption status between the two servers. As such, clients may b= e subject to selective disruption of communications by an intermediate ne= twork which disrupts communications based on keywords found through Deep = Packet Inspection. While many operators have commited to only establishin= g encrypted links from their servers in recognition of this vulnerability= , it remains impossible for users to audit this behavior and encrypted co= nnections are not required by the protocol itself . In particular, section 13.14 of the protocol specification explicitly acknowledges the existence of a downgrade atta= ck where an adversary controlling an intermediate network can force the i= nter domain federation between servers to revert to a non-encrypted proto= col were selective messages can then be disrupted.

Group chat in the XMPP protocol is defined as an extension within the = XML specification of the XMPP protocol (https://xmpp.org/extensions/xep-0= 045.html). However, it is not encoded or required at a protocol level, an= d not uniformly implemented by clients. The design of multi-user chat in the XMPP protocol suffers from extend= ing a protocol that was not designed with assembly of many users in mind.= In particular, in the federated protocol provided by XMPP, multi-user co= mmunities are implemented with a distinguished =E2=80=98owner=E2=80=99, w= ho is granted control over the participants and structure of the conversa= tion. Multi-user chat rooms are identified by a name specified on a specific= server, so that while the overall protocol may be federated, the ability= for users to assemble in a given community is moderated by a single serv= er. That server may block the room and prevent assembly unilaterally, eve= n between two users neither of whom trust or use that server directly.

Peer-to-Peer (P2P) is a network architecture (defined in ) in which all the participant nodes are equally responsible e= ngaged into the storage and dissemination of information. A P2P network i= s a logical overlay that lives on top of the physical network, and allows= nodes (or =E2=80=9Cpeers=E2=80=9D) participating to it to establish cont= act and exchange information directly from one to each other. The impleme= ntation of a P2P network may very widely: it may be structured or unstruc= tured, and it may implement stronger or weaker cryptographic and anonymit= y properties. While its most common application has traditionally been fi= le-sharing (and other types of content delivery systems), P2P is increasi= ngly becoming a popular architecture for networks and applications that r= equire (or encourage) decentralization. A prime example is Bitcoin (and s= imilar cryptocurrencies), as well as Skype, Spotify and other proprietary= multimedia applications. In a time of heavily centralized online services, peer-to-peer is ofte= n seen as an alternative, more democratic, and resistant architecture tha= t displaces structures of control over data and communications and delega= tes all peers equally to be responsible for the functioning, integrity, a= nd security of the data. While in principle peer-to-peer remains critical= to the design and development of future content distribution, messaging,= and publishing systems, it poses numerous security and privacy challenge= s which are mostly delegated to individual developers to recognize, analy= ze, and solve in each implementation of a given P2P network.

Since content, and in some occasions peer lists, are safeguarded and d= istributed by its members, P2P networks are prone to what are generally d= efined as =E2=80=9Cpoisoning attacks=E2=80=9D. Poisoning attacks might be= directed directly at the data that is being distributed, for example by = intentionally corrupting it, or at the index tables used to instruct the peers where to fetch the data, or at routing tables, with the attempt of = providing connecting peers with lists of rogue or non-existing peers, wit= h the intention to effectively cause a Denial of Service on the network.<= /t>

Peer-to-Peer traffic (and BitTorrent in particular) represents a high = percentage of global Internet traffic and it has become increasingly popu= lar for Internet Service Providers to perform throttling of customers lin= es in order to limit bandwidth usage and= sometimes probably as an effect of the ongoing conflict between copyrigh= t holders and file-sharing communities . Throttling the peer-to-peer traffic makes some uses of P2P networks in= effective and it might be coupled with stricter inspection of users=E2=80= =99 Internet traffic through Deep Packet Inspection techniques which migh= t pose additional security and privacy risks.

One of the fundamental and most problematic issues with traditional pe= er-to-peer networks is a complete lack of anonymization of its users. For= example, in the case of BitTorrent, all peers=E2=80=99 IP addresses are = openly available to the other peers. This has lead to an ever-increasing = tracking of peer-to-peer and file-sharing users . A= s the geographical location of the user is directly exposed, and so could be his identity, t= he user might become target of additional harassment and attacks, being o= f physical or legal nature. For example, it is known that in Germany law = firms have made extensive use of peer-to-peer and file-sharing tracking s= ystems in order to identify downloaders and initiate legal actions lookin= g for compensations . It is worth noting that there are varieties of P2P networks that imple= ment cryptographic practices and that introduce anonymization of its user= s. Such implementations proved to be successful in resisting censorship o= f content, and tracking of the network peers. A primary example is FreeNe= t , a free software application designed to si= gnificantly increase the difficulty of users and content identification, = and dedicated to foster freedom of speech online .

In open-membership P2P networks, a single attacker can pretend to be m= any participants, typically by creating multiple fake identities of whate= ver kind the P2P network uses . Attackers can = use Sybil attacks to bias choices the P2P network makes collectively towa= rd the attacker=E2=80=99s advantage, e.g., by making it more likely that = a particular data item (or some threshold of the replicas or shares of a = data item) are assigned to attacker-controlled participants. If the P2P = network implements any voting, moderation, or peer review-like functional= ity, Sybil attacks may be used to =E2=80=9Cstuff the ballots=E2=80=9D tow= ard the attacker=E2=80=99s benefit. Companies and governments can use Sy= bil attacks on discussion-oriented P2P systems for =E2=80=9Castroturfing=E2= =80=9D or creating the appearance of mass grassroots support for some po= sition where there is none in reality.

Encrypted P2P and Anonymous P2P networks already emerged and provided = viable platforms for sharing material, publish content anonymously, and c= ommunicate securely . If adopted at large, w= ell-designed and resistant P2P networks might represent a critical compon= ent of a future secure and distributed Internet, enabling freedom of spee= ch and freedom of information at scale.

A Virtual Private Network (VPN) is a point-to-point connection that en= ables two computers to communicate over an encrypted tunnel. There are mu= ltiple implementations and protocols used in provisioning a VPN, and they= generally diversify by encryption protocol or particular requirements, m= ost commonly in proprietary and enterprise solutions. VPNs are used commo= nly either to enable some devices to communicate through peculiar network= configurations, or in order to use some privacy and security properties = in order to protect the traffic generated by the end user; or both. VPNs = have also become a very popular technology among human rights defenders, = dissidents, and journalists worldwide to avoid local illegitimate wiretap= ping and eventually also to circumvent censorship. Among human rights def= enders VPNs are often debated as a potential alternative to Tor or other = anonymous networks. Such comparison is misleading, as some of the privacy= and security properties of VPNs are often misunderstood by less tech-sav= vy users, which could ultimately lead to unintended problems. As VPNs increased in popularity, commercial VPN providers have started= growing in business and are very commonly picked by human rights defende= rs and people at risk, as they are normally provided with an easy-to-use = service and sometimes even custom applications to establish the VPN tunne= l. Not being able to control the configuration of the network, and even l= ess so the security of the application, assessing the general privacy and= security state of common VPNs is very hard. Often such services have bee= n discovered leaking information, and their custom applications have been= found flawed. While Tor and similar networks receive a lot of scrutiny f= rom the public and the academic community, commercial or non-commercial V= PN networks are way less analyzed and understood, and it might be valuabl= e to establish some standards to guarantee a minimal level of privacy and= security to those who need them the most.

One of the common misconception among users of VPNs is the level of an= onymity VPN can provide. This sense of anonymity can be betrayed by a num= ber of attacks or misconfigurations of the VPN provider. It is important = to remember that, contrarily to Tor and similar systems, VPN was not desi= gned to provide anonymity properties. From a technical point of view, the= VPN might leak identifiable information, or might be subject of correlat= ion attacks that could expose the originating address of the connecting u= ser. Most importantly, it is vital to understand that commercial and non-= commercial VPN providers are bound by the law of the jurisdiction they re= side in or in which their infrastructure is located, and they might be le= gally forced to turn over data of specific users if legal investigations = or intelligence requirements dictate so. In such cases, if the VPN provid= ers retain logs, it is possible that the information of the user is provi= ded to the user=E2=80=99s adversary and leads to his or her identificatio= n.

With VPN being point-to-point connections, the service providers are i= n fact able to observe the original location of the connecting users and = they are able to track at what time they started their session and eventu= ally also to which destinations they=E2=80=99re trying to connect to. If = the VPN providers retain logs for long enough, they might be forced to tu= rn over the relevant data or they might be otherwise compromised, leading= to the same data getting exposed. A clear log retaining policy could be = enforced, but considering that countries enforce very different levels of= data retention policies, VPN providers should at least be transparent on= what information do they store and for how long is being kept.

VPN providers very commonly rely on 3rd parties to provision the infra= structure that is later going to be used to run VPN endpoints. For exampl= e, they might rely on external dedicated server hosting providers, or on = uplink providers. In those cases, even if the VPN provider itself isn=E2=80= =99t retaining any significant logs, the information on the connecting us= ers might be retained by those 3rd parties instead, introducing an additi= onal collection point for the adversary.

Some studies proved that several commercial VPN providers and applicat= ions suffer of critical leakage of information through IPv6 due to improp= er support and configuration . This is gene= rally caused by a lack of proper configuration of the client=E2=80=99s IP= v6 routing tables. Considering that most popular browsers and similar app= lications have been supporting IPv6 by default, if the host is provided w= ith a functional IPv6 configuration, the traffic that is generated might = be leaked if the VPN application isn=E2=80=99t designed to manipulate suc= h traffic properly.

Similarly, VPN services that aren=E2=80=99t handling DNS requests and = are not running DNS servers of their own, might be prone to DNS leaking w= hich might not only expose sensitive information on the activity of the u= ser, but could also potentially lead to DNS hijacking attacks and followi= ng compromises.

As revelations of mass surveillance have been growing in the press, ad= ditional details on attacks on secure Internet communications have come t= o the public=E2=80=99s attention. Among these, VPN appeared to be a very = interesting target for attacks and collection efforts. Some implementatio= ns of VPN appear to be particularly vulnerable to identification and coll= ection of key exchanges which, some Snowden documents revealed, are syste= matically collected and stored for future reference. The ability of an ad= versary to monitor network connections at many different points over the = Internet, can allow them to perform traffic correlation attacks and ident= ify the origin of certain VPN traffic by cross referencing the connection= time of the user to the endpoint and the connection time of the endpoint= to the final destination. These types of attacks, although very expensiv= e and normally only performed by very resourceful adversaries, have been = documented to be already in practice and could= completely vanify the use of a VPN and ultimately expose the activity an= d the identity of a user at risk.

Every Internet user has run into the =E2=80=98404 Not Found=E2=80=99 H= ypertext Transfer Protocol (HTTP) status code when trying, and failing, t= o access a particular website . It is a response s= tatus that the server sends to the browser, when the server cannot locate= the URL. =E2=80=98403 Forbidden=E2=80=99 is another example of this clas= s of code signals that gives users information about what is going on. In= the =E2=80=98403=E2=80=99 case the server can be reached, but is blockin= g the request because the user is trying to access content forbidden to t= hem. This can be because the specific user is not allowed access to the c= ontent (like a government employee trying to access pornography on a work= -computer) or because access is restricted to all users (like social netw= ork sites in certain countries). As surveillance and censorship of the Internet is becoming more commonpla= ce, voices were raised at the IETF to introduce a new status code that in= dicates when something is not available for =E2=80=98legal reasons=E2=80=99= (like censorship): The 451 status code would allow server operators to operate with great= er transparency in circumstances where issues of law or public policy aff= ect their operation. This transparency may be beneficial both to these op= erators and to end-users . The status code would be named =E2=80=98451=E2=80=99, a reference to B= radbury=E2=80=99s famous novel on censorship During the IETF meeting in Dallas, there was discussion about the usef= ulness of =E2=80=98451=E2=80=99. The main tension revolved around the lac= k of an apparent machine-readable technical use of the information. The e= xtent to which =E2=80=98451=E2=80=99 is just =E2=80=98political theatre=E2= =80=99 or whether it has a concrete technical use was heatedly debated. S= ome argued that =E2=80=98the 451 status code is just a status code with a= response body=E2=80=99 others said it was problematic because =E2=80=98i= t brings law into the picture=E2=80=99. Again others argued that it would= be useful for individuals, or organizations like the =E2=80=98Chilling E= ffects=E2=80=99 project, crawling the web to get an indication of censors= hip (IETF discussion on =E2=80=98451=E2=80=99 =E2=80=93 author=E2=80=99s = field notes March 2015). There was no outright objection during the Dalla= s meeting against moving forward on status code =E2=80=98451=E2=80=99, an= d on December 18, 2015 the Internet Engineering Steering Group approved p= ublication of =E2=80=98An HTTP Status Code to = Report Legal Obstacles=E2=80=99. It is now an IETF approved HTTP status c= ode to signal when resource access is denied as a consequence of legal de= mands . What is interesting about this particular case is that not only techni= cal arguments but also the status code=E2=80=99s outright potential polit= ical use for civil society played a substantial role in shaping the discu= ssion, and the decision to move forward with this technology. It is however important to note that 451 is not a solution to detect a= ll occasions of censorship. A large swath of Internet filtering occurs in= the network rather than the server itself. For these forms of censorship= 451 plays a limited role, as the servers will not be able to send the co= de, because they haven=E2=80=99t received the requests (as is the case wi= th servers with resources blocked by the Chinese Golden shield). Such fil= tering regimes are unlikely to voluntarily inject a 451 status code. The = use of 451 is most likely to apply in the case of cooperative, legal vers= ions of content removal resulting from requests to providers. One can thi= nk of content that is removed or blocked for legal reasons, like copyrigh= t infringement, gambling laws, child abuse, et cetera. The major use case= is thus clearly on the Web server itself, not the network. Large Interne= t companies and search engines are constantly asked to censor content in = various jurisdictions. 451 allows this to be easily discovered, for insta= nce by initiatives like the Lumen Database. In the case of adversarial bl= ocking done by a filtering entity on the network 451 is less useful. Overall, the strength of 451 lies in its ability to provide transparen= cy by giving the reason for blocking, and giving the end-user the ability= to file a complaint. It allows organizations to easily measure censorshi= p in an automated way, and prompts the user to access the content via ano= ther path (e.g. TOR, VPNs) when (s)he encounters the 451 status code.= Status code 451 impact human rights by making censorship more transpar= ent and measurable. The status code increases transparency both by signal= ing the existence of censorship (instead of a much more broad HTTP error = message like HTTP status code 404) as well as providing details of the le= gal restriction, which legal authority is imposing it, and what class of = resources it applies to. This empowers the user to seek redress.

On the current Internet, transparency on how packets reach a destinati= on is no longer a given. This is due to the increased presence of firewal= ls, spam filters, and network address translators networks (NATs) =E2=80=93= or middleboxes as these hosts are often called =E2=80=93 that make use o= f higher-layer fields to function . This development is contentious. The debate also unfolded at the IETF, sp= ecifically at the Session Protocol Underneath Datagrams (SPUD) Birds of a= Feather (BOF) meeting held at the IETF conference in March 2015. The dis= cussion at the BOF focused on questions about adding meta-data, or other = information to traffic flows, to enable the sharing of information with m= iddleboxes in that flow. During the sessions two competing arguments were= distilled. On the one hand adding additional data would allow for networ= k optimization, and hence improve traffic carriage. On the other hand, th= ere are risks of information leakage and other privacy and security conce= rns. Middleboxes, and the protocols guiding them, influence individuals=E2=80= =99 ability to communicate online freely and privately. Repeatedly mentio= ned in the discussion was the danger of censorship that comes with middle= boxes, and the IETF=E2=80=99s role to prevent such censorship from happen= ing. Middleboxes are becoming a proxy for the debate on the extent to whi= ch commercial interests are a valid reason to undermine the end-to-end pr= inciple. The potential for abuse and censoring, and thus ultimately the i= mpact of middleboxes on the Internet as a place of unfiltered, unmonitore= d freedom of speech, is real. It is impossible to make any definitive sta= tements about the direction the debate on middleboxes will take at the IE= TF. The opinions expressed in the SPUD BOF and by the various interviewee= s indicate that a majority of engineers are trying to mitigate the negati= ve effects of middleboxes on freedom of speech, but their ability to act = is limited by their larger commercial context that is expanding the use o= f middleboxes.

Are Distributed Denial of Service (DDoS) attacks a legitimate form of = online protest protected by the right to freedom of speech and associatio= n? Can they be seen as the equivalent to =E2=80=98million-(wo)men marches= =E2=80=99, or sit-ins? Or are they a threat to freedom of expression and = access to information, by limiting access to websites and in certain case= s the freedom of speech of others? These questions are crucial in our day= and age, where political debates, civil disobedience and other forms of = activism are increasingly moving online. Many individuals, not excluding IETF engineers, have argued that DDoS = attacks are fundamentally against freedom of speech. Technically DDoS att= acks are when one or multiple host overload the bandwidth or resources of= another host by flooding it with traffic, causing it to temporarily stop= being available to users. One can roughly differentiate three types of D= DoS attacks: Volume Based Attacked (This attack aims to make the host unr= eachable by using up all it=E2=80=99s bandwith, often used techniques are= : UDP floods and ICMP floods), Protocol Attacks (This attacks aims to use= up actual server resources, often used techniques are SYN floods, fragme= nted packet attacks, and Ping of Death ) and Ap= plication Layer Attacks (this attack aims to bring down a server, such as= the webserver). In their 2010 report Zuckerman et al argue that DDoS attacks are a bad= thing because they are increasingly used by governments to attack and si= lence critics. Their research demonstrates that in many countries indepen= dent media outlets and human rights organizations are the victim of DDoS = attacks, which are directly or indirectly linked to their governments. Th= ese types of attacks are particularly complicated because attribution is = difficult, creating a situation in which governments can effectively cens= or content, while being able to deny involvement in the attacks . DDoS attacks can thus stifle freedom of expression, = complicate the ability of independent media and human rights organization= s to exercise their right to (online) freedom of association, while facil= itating the ability of governments to censor dissent. When it comes to c= omparing DDoS attacks to protests in offline life, it is important to rem= ember that only a limited number of DDoS attacks involved solely willing = participants. In most cases, the clients are hacked computers of unrelate= d parties that have not consented to being part of a DDoS (for exceptions= see Operation Abibil or the Iranian Green Move= ment DDoS ). In addition, DDoS attacks are increasingly used as an extortion tactic= , with criminals flooding a website =E2=80=93 rendering it inaccessible =E2= =80=93 until the owner pays them a certain amount of money to stop the at= tack. The costs of mitigating such attacks, either by improving security = to prevent them or paying off the attackers, ends up being paid by the co= nsumer. All of these issues seem to suggest that the IETF should try to ensure= that their protocols cannot be used for DDoS attacks. Decreasing the num= ber of vulnerabilities in the network stacks of routers or computers, red= ucing flaws in HTTPS implementations, and depreciating non-secure HTTP pr= otocols could address this issue. The IETF can clearly play a role in bri= nging about some of these changes, and has indicated in its commitment to mitigating =E2=80=98pervasive monitoring (=E2= =80=A6) in the design of IETF protocols, where possible.=E2=80=99 This me= ans the use of encryption should become standard. Effectively, for the we= b this means standardized use of HTTPS. The IETF could redirect its work = such that HTPPS becomes part-and-parcel of its standards. However, next t= o the various technical trade-offs that this might lead to it is importan= t to consider that DDoS attacks are sometimes seen as a method for exerci= sing freedom of speech. DDoS although disruptive, and silencing at times, can also enable as p= rotest and speech. Or as Sauter argues: =E2=80=98= though DDoS as a tactic is still relatively novel, it fits within a centu= ries- long tradition of breaking laws and disrupting business as usual to= make a political point. These actions aren=E2=80=99t simply disruption f= or disruption=E2=80=99s sake. Rather they serve to help the activist or d= issenter to direct the attention of the public through the interpolation = of difference into routine.=E2=80=99 (30-31). An often heard argument aga= inst DDoS attacks is that you cannot construe it as a means to exercise y= our right to freedom of speech, when the means used effectively impede th= e right of the party on the receiving end of the attack to exercise that = same right. The problem with this line of argumentation is that it conven= iently ignores the fact that online DDoS attacks are often one of the few= effective ways for activists to gain the attention of the media, the gov= ernment or other parties of interest. Simply putting up a website for a c= ause won=E2=80=99t garner the same amount of attention as directly confro= nting the issue via the website of the individual or organization at the = heart of the issue. The ability of activists to do so should be protected= , especially considering the fact that as Sauter (2014:4) explains: =E2=80= =98Collectively, we have allowed the construction of an entire public sph= ere, the Internet, which by accidents of evolution and design, has none o= f the inherent free speech guarantees we have come to expect. Dissenting = voices are pushed out of the paths of potential audiences, effectively re= moving them from the public discourse. There is nowhere online for an act= ivist to stand with her friends and her sign. She might set up a dedicate= d blog=E2=80=94which may or may not ever be read=E2=80=94but it is much h= arder for her to stand collectively with others against a corporate giant= in the online space.=E2=80=99 Although the Internet is often compared to= public space, it is not. Rather the opposite. The Internet is almost ent= irely owned by private entities. And the IETF plays a crucial role in dev= eloping this privatized commercialized Internet. From a legal and political perspective, the IETF does not have the leg= itimacy to determine when a DDoS is legitimate (in legal or political ter= ms). It does not have the capability to make this judgment as a matter of= public policy and subsequently translate it to code. Nor should the IETF= try to do so. From a technical perspective, the difference between a =E2= =80=98legitimate=E2=80=99 and =E2=80=98illegitimate=E2=80=99 DDoS attack = is meaningless because it would be extremely difficult for the IETF to en= gineer a way to detect that difference. In addition, there is a need for = the IETF to be consistent in the face of attacks (an attack is an attack = is an attack) to maintain the viability of the network. Arguing that some= DDoS attacks should be allowed, based on the motivation of the attackers= complicates the work of the IETF. Because it approaches PM regardless of= the motivation of the attackers (see ) for rea= soning), taking the motivation of the attackers into account for DDoS wou= ld indirectly undermine the ability of the IETF to protect the right to p= rivacy because it introduces an element of inconsistency into how the IET= F deals with attacks. David Clark recently published a paper warning that the future of the = Internet is in danger. He argues that the private sector control over the= Internet is too strong, limiting the myriad of ways in which it can be u= sed , including for freedom of speech. But jus= t because freedom of speech, dissent, and protest are human rights, and D= DoS is a potential expression of those rights, doesn=E2=80=99t mean that = DDoS in and of itself is a right. To widen the analogy, just because the= Internet is a medium through which the right to freedom of expression ca= n be exercised does not make access to the Internet or specific ICTs or N= CTs a human right. Uses of DDoS might or might not be legitimate for poli= tical reasons, but the IETF has no means or methods to assess this, and i= n general enabling DDoS would mean a deterioration of the network and thu= s freedom of expression. In summation, the IETF cannot be expected to take a moral stance on DD= oS attacks, or create protocols to enable some attacks and inhibit others= =2E But what it can do is critically reflect on its role in creating a co= mmercialized Internet without a defacto public space or inherent protecti= ons for freedom of speech.

= Having established how human rights relate to standards and protocols,= a common vocabulary of technical concepts that impact human rights and h= ow these technical concept can be combined to ensure that the Internet re= mains an enabling environment for human rights means the contours of a mo= del for developing human rights protocol considerations has taken shape. = This subsection provides the last step by detailing how the technical con= cepts identified above relate to human rights, and what questions enginee= rs should ask themselves when developing or improving protocols. In short= , it presents a set of human rights protocol considerations.

Human rights threats on the Internet come in a myriad of forms. Protoc= ols and standards can harm or enable the right to freedom of expression, = right to non-discrimination, right to equal protection, right to particip= ate in cultural life, arts and science, right to freedom of assembly and = association, and the right to security. An end-user who is denied access = to certain services, data or websites may be unable to disclose vital inf= ormation about the malpractices of a government or other authority. A per= son whose communications are monitored may be prevented from exercising t= heir right to freedom of association. In a worst-case scenario, protocols= that leak information can lead to physical danger. A realistic example t= o consider is when opposition leaders in totalitarian regimes are subject= ed to torture on the basis of information gathered by the regime through = information leakage in protocols. This sections details several =E2=80=98common=E2=80=99 threats to huma= n rights, indicating how each of these can lead to human rights violation= s/harms and present several examples of how these threats to human rights= materialize on the Internet. This threat modeling is inspired by Privacy Considerations for Internet Protocols, which = is based on the security threat analysis. This method is by no means a pe= rfect solution for assessing human rights risks in Internet protocols and= systems; it is however the best approach currently available. Certain hu= man rights threats are indirectly considered in Internet protocols as par= t of the standard privacy and security considerations . Others suggestions are tailored specifically to human rights, an= d represents considerations not currently considered in other RFCs. Many threats, enablers and risks are linked to different rights. This = is not unsurprising if one takes into account that human rights are inter= related, interdependent and universal. Here however we=E2=80=99re not dis= cussing all human rights because not all human rights are relevant to ICT= s in general and protocols and standards in particular . This is by no means an attempt to cherry picks rights, if other r= ights seem relevant, please contact the authors and/or the hrpc mailingli= st.

This section provides guidance for document authors in the form of a q= uestionnaire about protocols being designed. The questionnaire may be use= ful at any point in the design process, particularly after document autho= rs have developed a high-level protocol model as described in . There should be some discussion of potential human rights risks arisin= g from potential misapplications of the protocol or technology described = in the RFC.This might be coupled with an Applicability Statement for that= RFC. Note that the guidance provided in this section does not recommend spe= cific practices. The range of protocols developed in the IETF is too broa= d to make recommendations about particular uses of data or how human righ= ts might be balanced against other design goals. However, by carefully c= onsidering the answers to each question mentioned under 7.3, document aut= hors should be able to produce a comprehensive analysis that can serve as= the basis for discussion on whether the protocol adequately protects aga= inst human rights threats. This guidance is meant to help the thought pr= ocess of a human rights analysis; it does not provide specific directions= for how to write a human rights protocol considerations section (followi= ng the example set in ).

Question(s): Does your protocol add application-specific functions to intermediary nod= es? Could this functionality also be added to end nodes instead of interm= ediary nodes? Explanation: The end-to-end principle which aims to extend = characteristics of a protocol or system as far as possible within the sys= tem, or in other words =E2=80=98the intelligence is end to end rather tha= n hidden in the network=E2=80=99 . Middleboxes = (which can be Content Delivery Networks, Firewalls, NATs or other interme= diary nodes that provide other =E2=80=98services=E2=80=99 than routing), = and the protocols guiding them, influence individuals=E2=80=99 ability to= communicate online freely and privately. The potential for abuse and int= entional and unintentional censoring and limiting permissionless innovati= on, and thus ultimately the impact of middleboxes on the Internet as a pl= ace of unfiltered, unmonitored freedom of speech, is real. Example: End-to-end instant message encryption would conceal communications from o= ne user=E2=80=99s instant messaging application through any intermediate = devices and servers all the way to the recipient=E2=80=99s instant messag= ing application. If the message was decrypted at any intermediate point=E2= =80=93for example at a service provider=E2=80=93then the property of end-= to-end encryption would not be present. Impacts: Right to freedom of expression Right to freedom of assembly and association

Question(s): Did you have a look at the Guidelines in the Privacy Considerations for I= nternet Protocols section 7? Does your protoco= l in any way impact the confidentiality of protocol metadata? Does your p= rotocol countering traffic analysis, or data minimization? Explanation:=20 Privacy refers to the right of an entity (normally a person), acting in i= ts own behalf, to determine the degree to which it will interact with its= environment, including the degree to which the entity is willing to shar= e its personal information with others. . Example: See Impacts: Right to freedom of expression Right to non-discrimination

Question(s): If your protocol impacts packet handling, does it look at the packet cont= ent? Is it making decisions based on the content of the packet? Is the pr= otocol transparent about its decision? Does your protocol prioritize cert= ain content or services over others? Explanation: Content agnosticism refers to the notion that network traffic is treated = identically regardless of content. Example:=20 Content agnosticism prevents content-based discrimination against packets= =2E This is important because changes to this principle can lead to a two= -tiered Internet, where certain packets are prioritized over others on th= e basis of their content. Effectively this would mean that although all u= sers are entitled to receive their packets at a certain speed, some users= become more equal than others. Impacts: Right to freedom of expression Right to non-discrimination Right to equal protection

Question(s): Did you have a look at Guidelines for Writing RFC Text on Security Consid= erations ? Have you found any attacks that are = out of scope for your protocol? Would these attacks be pertinent to the h= uman rights enabling features of the Internet (as descibred throughout th= is document)? Explanation: Most people speak of security as if it were a single monolithic property = of a protocol or system, however, upon reflection; one realizes that it i= s clearly not true. Rather, security is a series of related but somewhat = independent properties. Not all of these properties are required for e= very application. We can loosely divide security goals into those related= to protecting communications (COMMUNICATION SECURITY, also known as COMS= EC) and those relating to protecting systems (ADMINISTRATIVE SECURITY or = SYSTEM SECURITY). Since communications are carried out by systems and acc= ess to systems is through communications channels, these goals obviously = interlock, but they can also be independently provided . Example:=20 See . Impacts: Right to freedom of expression Right to freedom of assembly and association Right to non discrimination

Question(s): Does your protocol have text strings that are readable or entered by huma= ns? Does your protocol allow Unicode encoded in UTF-8 only, thereby shift= ing conversion issues away from individual choices? Did you have a look a= t ? Explanation: Internationalization refers to the practice of making protocols, standard= s, and implementations usable in different languages and scripts. (see L= ocalization). In the IETF, internationalization means to add or improve t= he handling of non-ASCII text in a protocol. A= different perspective, more appropriate to protocols that are designed f= or global use from the beginning, is the definition used by W3C:

Many protocols that handle text only handle one charset (US-ASCII), or= leave the question of what CCS and encoding are used up to local guesswo= rk (which leads, of course, to interoperability problems). If multiple c= harsets are permitted, they must be explicitly identified . Adding non-ASCII text to a protocol allows the protocol to = handle more scripts, hopefully representing users across the world. In t= oday=E2=80=99s world, that is normally best accomplished by allowing Unic= ode encoded in UTF-8 only, thereby shifting conversion issues away from i= ndividual choices. Example: See localization Impacts: Right to freedom of expression Right to political participation Right to participate in cultural life, arts and science Right to political participation

Question(s): Does this protocol introduce new identifiers that might be associated wit= h persons or content? Does your protocol make it apparent or transparent = when filtering happens? Explanation: Censorship resistance refers to the methods and measures to prevent Inter= net censorship. Example: Identifiers of content exposed within a protocol might be used to facilit= ate censorship, as in the case of IP based censorship, which affects prot= ocols like HTTP. Filtering can be made apparent by the use of status code= 451 =E2=80=93 which allows server operators to operate with greater tran= sparency in circumstances where issues of law or public policy affect the= ir operation . Impacts: =E2=80=A2 Right to freedom of expression=20 =E2=80=A2 Right to political participation=20 =E2=80=A2 Right to participate in cultural life, arts and science=20 =E2=80=A2 Right to freedom of assembly and association

Is your protocol fully documented in a way that it could be easily imp= lemented, improved, build upon and/or further developed. Is there any pro= prietary code needed for the implementation, running or further developme= nt of your protocol? Impacts: Right to freedom of expression Right to participate in cultural life, arts and science

Question(s): Does your protocol support heterogeneity by design? Does your protocol al= low for multiple types of hardware? Does your protocol allow for multiple= types of application protocols? Explanation: The Internet is characterized by heterogeneity on many levels: devices an= d nodes, router scheduling algorithms and queue management mechanisms, ro= uting protocols, levels of multiplexing, protocol versions and implementa= tions, 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 administr= ative domains and pricing structures. As a result, the heterogeneity prin= ciple proposed in needs to be supported by des= ign . Example: Heterogeneity is inevitable and needs be supported by design. Multiple ty= pes of hardware must be allowed for, e.g. transmission speeds differing b= y at least 7 orders of magnitude, various computer word lengths, and host= s ranging from memory-starved microprocessors up to massively parallel su= percomputers. Multiple types of application protocol must be allowed f= or, ranging from the simplest such as remote login up to the most complex= such as distributed databases . Impacts:=20 =E2=80=A2 Right to freedom of expression

Question(s): Did you have a look at the Privacy Considerations for Internet Protocols = , especially section 6.1.1 ? Explanation:=20 Anonymity refers to the condition of an identity being unknown or conceal= ed . It is an important feature for many end-us= ers, as it allows them different degrees of privacy online. Example:=20 Often standards expose private information, it is important to consider w= ays to mitigate the obvious privacy impacts. For instance, a feature whic= h uses deep packet inspection or geolocation data could refuse to open th= is data to third parties, that might be able to connect the data to a phy= sical person. Impacts: =E2=80=A2 Right to non-discrimination =E2=80=A2 Right to political participation=20 =E2=80=A2 Right to freedom of assembly and association =E2=80=A2 Right to security

Question(s):=20 Have you considered the Privacy Considerations for Internet Protocols , especially section 6.1.2 ? Does this specificati= on collect personally derived data? Does the standard utilize data that i= s personally-derived, i.e. derived from the interaction of a single perso= n, or their device or address? Does this specification generate personall= y derived data, and if so how will that data be handled? Explanation:=20 Pseudonymity =E2=80=93 the ability to disguise one=E2=80=99s identity onl= ine =E2=80=93 is an important feature for many end-users, as it allows th= em different degrees of anonymity and privacy online. Example:=20 Designing a standard that exposes private information to ??, it is import= ant to consider ways to mitigate the obvious impacts. For instance, a fea= ture which uses deep packet inspection or geolocation data could refuse t= o open this data to third parties, that might be able to connect the data= to a physical person. Impacts: Right to non-discrimination Right to freedom of assembly and association

Question(s): Is your protocol designed to provide an enabling environment for people w= ho are not able-bodied? Have you looked at the W3C Web Accessibility Init= iative for examples and guidance? Is your protocol optimized for low band= width and high latency connections? Could your protocol also be developed= in a stateless manner? Explanation: The Internet is fundamentally designed to work for all people, whatever t= heir hardware, software, language, culture, location, or physical or ment= al ability. When the Internet meets this goal, it is accessible to people= with a diverse range of hearing, movement, sight, and cognitive ability = . Sometimes in the design of protocols= , websites, web technologies, or web tools, barriers are created that exc= lude people from using the Web. Example: The HTML protocol as defined in specifically r= equires that every image must have an alt attribute (with a few exception= s for HTML5) to ensure images are accessible for people that cannot thems= elves decipher non-text content in web pages. Impacts: =E2=80=A2 Right to non-discrimination =E2=80=A2 Right to freedom of assembly and association =E2=80=A2 Right to education =E2=80=A2 Right to political participation

Question(s): Does your protocol uphold the standards of internationalization? Have mad= e any concrete steps towards localizing your protocol for relevant audie= nces? Explanation: Localization refers to the adaptation of a product, application or docume= nt content to meet the language, cultural and other requirements of a spe= cific target market (a locale) . It is also = described as the practice of translating an implementation to make it fun= ctional in a specific language or for users in a specific locale (see Int= ernationalization). Example: The Internet is a global medium, but many of its protocols and products a= re developed with a certain audience in mind, that often share particular= characteristics like knowing how to read and write in ASCII and knowing = English. This limits the ability of a large part of the world=E2=80=99s o= nline population from using the Internet in a way that is culturally and = linguistically accessible. An example of a protocol that has taken into a= ccount the view that individuals like to have access to data in their nat= ive language can be found in . This protocol la= bels the information content with an identifier for the language in which= it is written. And this allows information to be presented in more than = one language. Impacts: =E2=80=A2 Right to non-discrimination=20 =E2=80=A2 Right to participate in cultural life, arts and science =E2=80=A2 Right to Freedom of Expression

Question(s): Can your protocol be implemented without one single point of control? If = applicable, can your protocol be deployed in a federated manner? What is = the potential for discrimination against users of your protocol? How can = use of your protocol be used to implicate users? Does your protocol crea= te additional centralized points of control? Explanation: Decentralization is one of the central technical concepts of the architec= ture, and embraced as such by the IETF . It ref= ers to the absence or minimization of centralized points of control =E2=80= =93 a feature that is assumed to make it easy for new users to join and n= ew uses to unfold {{Brown}. It also reduces issues surrounding single poi= nts of failure, and distributes the network such that it continues to fun= ction if one or several nodes are disabled. With the commercialization of= the Internet in the early 1990=E2=80=99s there has been a slow move to m= ove away from decentralization, to the detriment of the technical benefit= s of having a decentralized Internet. Example: The bits traveling the Internet are increasingly susceptible to monitorin= g and censorship, from both governments and Internet service providers, a= s well as third (malicious) parties. The ability to monitor and censor is= further enabled by the increased centralization of the network that crea= tes central infrastructure points that can be tapped in to. The creation = of peer-to-peer networks and the development of voice-over-IP protocols u= sing peer-to-peer technology in combination with distributed hash table (= DHT) for scalability are examples of how protocols can preserve decentral= ization . Impacts: =E2=80=A2 Right to freedom of assembly and association

Question(s): Is your protocol fault tolerant? Does it degrade gracefully? Do you have = a documented way to announce degradation? Do you have measures in place f= or recovery or partial healing from failure? Can your protocol maintain d= ependability and performance in the face of unanticipated changes or circ= umstances? Explanation: Reliability ensures that a protocol will execute its function consistentl= y and error resistant as described, and function without unexpected resul= t. A system that is reliable degenerates gracefully and will have a docum= ented way to announce degradation. It also has mechanisms to recover fro= m failure gracefully, and if applicable, allow for partial healing. As wi= th confidentiality, the growth of the Internet and fostering innovation i= n services depends on users having confidence and trust in the network. For reliability it is necessary that services n= otify the users if a delivery fails. In the case of real-time systems in = addition to the reliable delivery the protocol needs to safeguard timelin= ess. Example: In the modern IP stack structure, a reliable transport layer requires an = indication that transport processing has successfully completed, such as = given by TCP=E2=80=99s ACK message , and not si= mply an indication from the IP layer that the packet arrived. Similarly,= an application layer protocol may require an application-specific acknow= ledgement that contains, among other things, a status code indicating the= disposition of the request (See ). Impacts: =E2=80=A2 Right to security

Question(s): Does this protocol expose information related to identifiers or data? If = so, does it do so to each other protocol entity (i.e., recipients, interm= ediaries, and enablers) ? What options exist fo= r protocol implementers to choose to limit the information shared with ea= ch entity? What operational controls are available to limit the informati= on shared with each entity? What controls or consent mechanisms does the protocol define or requir= e before personal data or identifiers are shared or exposed via the proto= col? If no such mechanisms or controls are specified, is it expected tha= t control and consent will be handled outside of the protocol? Does the protocol provide ways for initiators to share different piece= s of information with different recipients? If not, are there mechanisms= that exist outside of the protocol to provide initiators with such contr= ol? Does the protocol provide ways for initiators to limit which informati= on is shared with intermediaries? If not, are there mechanisms that exis= t outside of the protocol to provide users with such control? Is it expe= cted that users will have relationships that govern the use of the inform= ation (contractual or otherwise) with those who operate these intermediar= ies? Does the protocol prefer encryption over clear text operation? Does the protocol provide ways for initiators to express individuals=E2= =80=99 preferences to recipients or intermediaries with regard to the col= lection, use, or disclosure of their personal data? Explanation: Confidentiality refers to keeping your data secret from unintended listen= ers . The growth of the Internet depends on use= rs having confidence that the network protects their private information = . Example: Protocols that do not encrypt their payload make the entire content of th= e communication available to the idealized attacker along their path. Fol= lowing the advice in , most such protocols have= a secure variant that encrypts the payload for confidentiality, and thes= e secure variants are seeing ever-wider deployment. A noteworthy exceptio= n is DNS , as DNSSEC = does not have confidentiality as a requirement. This implies that, in th= e absence of changes to the protocol as presently under development in th= e IETF=E2=80=99s DNS Private Exchange (DPRIVE) working group, all DNS q= ueries and answers generated by the activities of any protocol are availa= ble to the attacker. When store-and-forward protocols are used (e.g., SM= TP ), intermediaries leave this data subject to= observation by an attacker that has compromised these intermediaries, un= less the data is encrypted end-to-end by the application-layer protoco= l or the implementation uses an encrypted store for this data . Impacts: Right to security

Question(s): Does your protocol maintain and assure the accuracy of data? Does your pr= otocol maintain and assure the consistency of data? Does your protocol in= any way allow for the data to be (intentionally or unintentionally) alte= red? Explanation:=20 Integrity refers to the maintenance and assurance of the accuracy and con= sistency of data to ensure it has not been (intentionally or unintentiona= lly) altered. Example:=20 See authenticity Impacts: Right to security

Question(s): Do you have sufficient measures to confirm the truth of an attribute of a= single piece of data or entity? Can the attributes get garbled along the= way (see security)? If relevant have you implemented IPsec, DNSsec, HTTP= S and other Standard Security Best Practices? Explanation:=20 Authenticity ensures that data does indeed come from the source it claims= to come from. This is important to prevent attacks or unauthorized acces= s and use of data. Example:=20 Authentication of data is important to prevent vulnerabilities and attack= s, like man-in-the-middle-attacks. These attacks happen when a third part= y (often for malicious reasons) intercepts a communication between two pa= rties, inserting themselves in the middle and posing as both parties. In = practice this looks as follows: Alice wants to communicate with Bob. Alice sends data to Bob. Niels intercepts the data sent to Bob. Niels reads and alters the message to Bob. Bob cannot see the data did not come from Alice but from Niels. Niels intercepts and alters the communication as it is sent between Alice= and Bob. Niels knows all. Impacts: Right to security

Question(s): Do your protocols follow the principle of non-discrimination? Do your pro= tocols follow the principle of content agnosticism? Does your protocol ta= ke into account the needs of special needs (Internet) groups, like the au= dio-visually impaired? Also see availability. Explanation:=20 The Internet is a global medium. Yet, there continue to be issues surroun= ding acceptability =E2=80=93 the extent to which standards are non-discri= minatory and relevant to the widest range of end-users =E2=80=93 that nee= d to be resolved. Many standards are not suitable for end-users who are n= ot-ablebodied, or otherwise restricted in their ability to access the Int= ernet in its current form (text, data and English heavy). Development of = new standards should consider the ways in which they exclude or include n= on-traditional user communities. Example: Designing a feature that could make access to websites for no= n-able bodied people more difficult. Right to education Right to freedom of expression Right to freedom of assembly and association

Question(s): Does your standard favor proprietary specifications over technically equi= valent and competing specification(s) by making any incorporated vendor s= pecification =E2=80=9Crequired=E2=80=9D or =E2=80=9Crecommended=E2=80=9D = ? Does your protocols use proprietary code? Doe= s your protocol depend on proprietary code? Also see =E2=80=98Open Standa= rds=E2=80=99 above. Also see =E2=80=98Connectivity=E2=80=99 above. Explanation:=20 An open, balanced and cooperative approach to developing technological st= andards is vital to maintaining the Internet open, accessible and secure.= This will ensure the standards are open and not subject to restrictive c= ontract terms from the copyright owners. Availability of standards is a p= rerequisite to the continued growth of the Internet, and crucial to conti= nued technological innovation across the globe. Example:=20 See Open Standards Impacts: Right to education

Question(s): Does your protocol impact permissionless innovation? See =E2=80=98Connect= ivity=E2=80=99 above. Explanation:=20 Adaptability is closely interrelated permissionless innovation, both main= tain the freedom and ability to freely create and deploy new protocols on= top of the communications constructs that currently exist. It is at the = heart of the Internet as we know it, and to maintain its fundamentally op= en nature, we need to be mindful of the impact of protocols on maintainin= g or reducing permissionless innovation to ensure the Internet can contin= ue to develop. Example:=20 WebRTC generates audio and/or video data. In order to ensure that WebRTC = can be used in different locations by different parties it is important t= hat standard Javascript APIs are developed to support applications from d= ifferent voice service providers. Multiple parties will have similar capa= bilities, in order to ensure that all parties can build upon existing sta= ndards these need to be adaptable, and allow for permissionless innovatio= n. Impacts: Right to education Freedom of expression Freedom of assembly and association