Article19

niels@article19.org

General Human Rights Protocol Considerations Research Group Internet-Draft Anonymity is less discussed topic in the IETF than for instance security or privacy . This can be attributed to the fact anonymity is a hard technical problem or that anonymizing user data is not of specific market interest. It remains a fact that ‘most internet users would like to be anonymous online at least occasionally’ . This document aims to break down the different meanings and implications of anonymity on a mediated computer network.

There seems to be a clear need for anonymity when harassment on the Internet on the increase and the UN Special Rapporteur for Freedom of Expression call anonymity ‘necessary for the exercise of the right to freedom of opinion and expression in the digital age’ . Nonetheless anonymity is not getting much discussion at the IETF, providing anonymity does not seem a (semi-)objective for many protocols, even though several documents contribute to improving anonymity such as , , . There are initiatives on the Internet to improve end users anonymity, most notably , but this all relies on adding encryption in the application layer. This document aims to break down the different meanings and implications of anonymity on a mediated computer network and to see whether (some parts of) anonymity should be taken into consideration in protocol development.

Concepts in this draft currently strongly hinges on A state of an individual in which an observer or attacker cannot identify the individual within a set of other individuals (the anonymity set). Linkability of two or more items of interest (IOIs, e.g., subjects, messages, actions, …) from an attacker’s perspective means that within the system (comprising these and possibly other items), the attacker can sufficiently distinguish whether these IOIs are related or not. Dervided from pseudonym, a persistent identity which is not the same as the entity’s given name. Unlinkability of two or more items of interest (IOIs, e.g., subjects, messages, actions, …) from an attacker’s perspective means that within the system (comprising these and possibly other items), the attacker cannot sufficiently distinguish whether these IOIs are related or not. The impossibility of being noticed or discovered Undetectability of an item of interest (IOI) from an attacker’s perspective means that the attacker cannot sufficiently distinguish whether it exists or not undetectability of the IOI against all subjects uninvolved in it and anonymity of the subject(s) involved in the IOI even against the other subject(s) involved in that IOI.

Premise: activity on the network has the ability for is to be anonymous or authenticated While analyzing protocols for their impact on users anonymity, would it make sense to ask the following questions: How anonymous is the end user to: local network operator other networks you connect to your communications peer on the other end of the pipe How well can they distinguish my identity from somebody else (with a similar communication) (ie linkability) How does the protocol impact pseudonomity? in case of long term pseudonymity in case of short term pseudonymity How does the protocol, in conjunction with other protocols, impact pseudonymity? Could there be advice for prootocol developers and implementers to improve anonimity and pseudonymity?

multiple identities concurrently used, mixing them in operations / keeping them distinct (talking to XMPP, alias, etc) when you change identity, do cross stack analysis, so you have no bleedover, anonymity on a cross protocol, cross stack level

As this draft concerns a research document, there are no security considerations.

This document has no actions for IANA.

The discussion list for the IRTF Human Rights Protocol Considerations proposed working group is located at the e-mail address hrpc@ietf.org. Information on the group and information on how to subscribe to the list is at https://www.irtf.org/mailman/listinfo/hrpc Archives of the list can be found at: https://www.irtf.org/mail-archive/web/hrpc/current/index.html

All RFCs are required to have a Security Considerations section. Historically, such sections have been relatively weak. This document provides guidelines to RFC authors on how to write a good Security Considerations section. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document offers guidance for developing privacy considerations for inclusion in protocol specifications. It aims to make designers, implementers, and users of Internet protocols aware of privacy-related design choices. It suggests that whether any individual RFC warrants a specific privacy considerations section will depend on the document's content. Pervasive monitoring is a technical attack that should be mitigated in the design of IETF protocols, where possible. This document describes the privacy issues associated with the use of the DNS by Internet users. It is intended to be an analysis of the present situation and does not prescribe solutions. This document describes the use of Transport Layer Security (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7626. In addition, this document specifies two usage profiles for DNS over TLS and provides advice on performance considerations to minimize overhead from using TCP and TLS with DNS.This document focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE Working Group. It does not prevent future applications of the protocol to recursive-to-authoritative traffic.