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

[Niels ten Oever <[e-mail]>]

Hi Joss,

Thanks for this. Reply inline:


On 02/09/2017 10:34 PM, Joss Wright wrote:
> 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. 
> 


​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}}.


> 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"?

​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 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'. 

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

> 
> 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'.)

​see above.

> 
> * 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.)

​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.

> 
> 5.2.3.2.2
> 
> 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)


> 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.
> 

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

> 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.)


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

> 
> 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. 
> 

​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.​

> 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.
> 

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.

​

> 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.
> 

​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?​

> <End of comments>
> 
> As I said, apologies for not being more thorough.

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

Best,

Niels