Subject: [hrpc] Comments on "Research into Human Rights Protocol Considerations"

From: Joss Wright <[email-masked]>
Date: Thu, 9 Feb 2017 21:34:25 +0000

Hello,

I just read through the "Research into Human Rights Protocol
Considerations" document. I have a few, relatively random, comments from
my read-through. (Apologies here -- I didn't have time to do a really
thorough review, and there were a few points about which I was slightly
uncomfortable or felt that the document neglected or, alternatively,
overemphasised. It seemed best not to let the perfect be the enemy of
the good, though, so am sending these comments along anyway.)

<Comments follow.>

Section 2:

* Censorship-resistance

Censorship has not yet been at this point defined -- that definition
should probably come in first. 

I also have a general problem with the political implications of 'censorship',
although I accept its widespread use. It might be nice to have the distinction
drawn between the technical terms such as 'filtering' and 'blocking', and the
more normatively-loaded term "censorship"?

Censorship is brought in later in this section as 'internet censorship'. I
would argue that you should harmonise the terms -- if you use 'internet
censorship' and not just 'censorship' then you should also use 'internet
censorship resistance'. 

I can see that this definition is partially taken from Elahi and
Goldberg, but what is this 'relevant for decision making' element? Is
suppression of, say, works of art not censorship by this definition?
(For that matter, is removal of child pornography not 'censorship'? This
is precisely why I prefer terms such as 'filtering'.)

* Strong encryption 

I checked the referenced RFC, but didn't see this definition of 'a large amount
of computing power'. I would argue that modern usage of 'strong encryption'
implies an amount of computing power infeasible even for major state-level
actors. (If implemented correctly.)

5.2.3.2.2

Maybe add 'overblocking' to the definitions list?

For DNS, maybe distinguish between 'fake response' (incorrect IP) and 'no
response' (nxdomain -- claiming that no such site exists).

5.2.3.5.1

This is an integrity issue, and integrity is not mentioned in this paragraph.
(Also, this feels like it's moving beyond a 'standards' issue? I'm not sure if
this is really falling within scope.)

As a side note, the inclusion of XMPP around this section of the document here
feels a little arbitrary -- especially the amount of the document devoted to
it.

5.2.3.5.2

You might want to mention the case of Iran throttling HTTPS connections,
causing users to switch to (unthrottled) HTTP to enable surveillance. I've kind
of lost track of the levels of subsections, though, so that may not be
appropriate here if you're focusing on p2p. (It would be elsewhere, though, as
the general issue of affordances is probably worth talking about -- if people
don't use the secure/rights-defending tools due to other constraints, such as a
lack of usability, then they have little impact.)

6.2.10

I would say "Pseudonymity -- the ability to use a persistent identifier not
linked to one's offline identity" straight away over simply 'disguise one's
identity', as 'disguise' is more easily confused with anonymity. 

I would also include consideration that pseudonyms cannot be simply reverse
engineered -- some early approaches simply took approaches such as simple
hashing of IP addreses. These could then be simply reversed by generating a
hash for each potential IP address and comparing it to the pseudonym.

6.2.14

I would draw a distinction between 'random degradation' and 'malicious
degradation'. Many current attacks against TLS, for example, exploit TLS's
ability to gracefully degrade to older cipher suites -- from  a functional
perspective, this is good. From a security perspective, this can be very bad.

<End of comments>

As I said, apologies for not being more thorough.

Joss
-- 
Dr. Joss Wright | Research Fellow
Oxford Internet Institute, University of Oxford
Co-Director, Oxford University Cybersecurity Doctoral Training Centre
Faculty Fellow, Alan Turing Institute
http://www.oii.ox.ac.uk/people/?id=176

---

From: Niels ten Oever <[email-masked]>
Date: Mon, 13 Feb 2017 15:45:30 +0100

Hi Joss,

Thanks for this. Reply inline:

> should probably come in first. 

​We have added the following three definitions to draft:

Blocking: the practice of preventing access to resources in the
aggregate {{RFC 7754}}. Both blocking and filtering can be implemented
at the level of "services" (web hosting or video streaming, for example)
or at the level of particular "content."  {{RFC 7754}}

https://tools.ietf.org/html/rfc7754

Censorship: technical mechanisms, that include both blocking and
filtering, that certain political or private actors around the world use
to block or degrade Internet traffic. For further details on the various
elements of Internet censorship see {{Hall2016}}

https://tools.ietf.org/html/draft-hall-censorship-tech-04

Filtering: the practice of preventing access to specific resources
within an aggregate {{RFC 7754}}.

> more normatively-loaded term "censorship"?

​Agreed - however, we hope that the newly added definitions based on
existing IETF drafts and documents clarify that in this particular case,
censorship does not come with a normatively loaded backpack, but rather
is seen as an umbrella term for filtering and blocking.​

> censorship' and not just 'censorship' then you should also use 'internet

​We removed the definition by Elahi, to reduce confusion and stick to
the narrow technical definition of censorship. ​

> is precisely why I prefer terms such as 'filtering'.)

​see above.

> actors. (If implemented correctly.)

​Updated the language. It now reads:

Strong encryption / cryptography
Used to describe a cryptographic algorithm that would require a large
amount of computational power to defeat it [RFC4949]. In the modern
usage of the definition 'strong encryption' this refers to an amount of
computing power current not available, not even to major state-level
actors.

> Maybe add 'overblocking' to the definitions list?

Changed the sentence into:

A notable instance of distortion occurred in Greece {{ververis}}, where
a study found evidence of both of deep packet inspection to distort DNS
replies, and more excessive blocking of content than was legally
required or requested (also known as overblocking)

> feels a little arbitrary -- especially the amount of the document devoted to

This is part of the case studies is showing the relation between human
rights and protocols, a combination of protocols and their implementations.

> lack of usability, then they have little impact.)

Added the following text to the analysis of HTTP and HTTPS (TLS):

While this is commendable, we must not lose track of the fact that
different protocols, implementations, configurations and networking
paradigms can intersect such that they (can be used to) adversely impact
human rights. For instance, certain countries will throttle HTTPS
connections forcing users to switch to the (unthrottled) HTTP to
facilitate surveillance {{Aryanetall}}.

https://jhalderm.com/pub/papers/iran-foci13.pdf

> identity', as 'disguise' is more easily confused with anonymity. 

​Updated the definition. It now reads: Pseudonymity - the ability to use
a persistent identifier not linked to one's offline identity" straight
away - is an important feature for many end-users, as it allows them
different degrees of disguised identity and privacy online.​

> hash for each potential IP address and comparing it to the pseudonym.

Update the language, it now reads:

Designing a standard that exposes private information, it is important
to consider ways to mitigate the obvious impacts. While pseudonyms
cannot be simply reverse engineered - some early approaches simply took
approaches such as simple hashing of IP addreses, these could then be
simply reversed by generating a hash for each potential IP address and
comparing it to the pseudonym - limiting the exposure of private
information remains important.

​

> perspective, this is good. From a security perspective, this can be very bad.

​Added two new bits to 6.2.14:
Under Explanation:

It is important here to draw a distinction between random degradation
and malicious degradation. Many current attacks against TLS, for
example, exploit TLS's ability to gracefully degrade to older cipher
suites -- from  a functional perspective, this is good. From a security
perspective, this can be very bad.​

​Also added the following question:

Can your protocol resist malicious degradation attempts?​

> As I said, apologies for not being more thorough.

​No apologies - this was very thorough and we thoroughly appreciate it.

Best,

Niels