Re: [hrpc] Protocol/Architecture consideration of Attribution & right of legal remedy (was: Re: I-D Action: draft-irtf-hrpc-guidelines-03.txt)

On 6/9/19 9:36 PM, John Curran wrote:
> On 7 Jun 2019, at 4:30 AM, internet-drafts@ietf.org wrote:
>>   This document sets guidelines for human rights considerations in
>>   networking protocols, similar to the work done on the guidelines for
>>   privacy considerations [RFC6973].  This is an updated version of the
>>   guidelines for human rights considerations in [RFC8280].
> 
> Folks - 
> 
> The draft notes that the human right of legal remedy (recourse before competent tribunal for violations of other fundamental rights) may be relevant when evaluating impacts of a protocol/architecture, but does not presently show any example of a relationship within the various consideration sections.  
> 
> I would note that, encouraged by the operator community, the IETF has previously considered possible impacts that various architecture & protocols can have on this human right – as effective legal remedy often requires attribution in order to determine applicable law and jurisdiction and protocols/archictures can significantly preclude attribution.  For an example of IETF consideration of one such consideration, see BCP162/RFC6302 ("Logging Recommendations for Internet-Facing Servers”) that provides logging recommendations to facilitate better endpoint attribution during abuse and public safety queries.
> 
> It is not necessary for draft-irtf-hrpc-guidelines to reflect the potential for protocols/architectures to impact the human right of legal remedy, but I believe that omitting an any reference will result in a guide for conducting HR reviews which is incomplete, and not reflect the understanding already present in the community that that there are indeed tradeoffs in human right tradeoffs being made in protocol design – hopefully tradeoffs that consider the overall intent of the IETF to have an Internet which supports effective exercise of the rights of freedom of expression and association.
> 
> To that end, I’d suggest adding the following section on "Attribution to present list of considerations used during protocol assessment.
> 
> Thanks!
> /John
> 
> ===
> 
> 3.3.n  Attribution
> 
>    Question(s): Does your protocol/architecture prevent attribution of those parties 
>    involved in communication, and can the protocol readily be used for communication
>    which harm the security of recipient?  What, if any, mechanisms within the protocol 
>    or architecture are provided for a recipient of communications to obtain redress
>    from communication which causes harm?  If no such mechanisms available, does 
>    the protocol/architecture provide sufficient information attributing the source of 
>    communication to facilitate a recipient exercising their right to legal remedy? 
> 
>    Explanation: While anonymity and pseudonymity are very important attributes 
>    for protecting several human rights (e.g. those related to freedom of expression 
>    and association),  it is also possible for parties to use communication capabilities
>    to harm others.  Protocols/architectures should consider the potential for harm in
>    their use, the architectural mechanisms available to mitigate this risk of harm, the 
>    protocol properties that might impact persons exercising their right of legal remedy,
>    and the resulting impact to individuals right of security of person when using the 
>    protocol. 
> 
>    Impacts:
> 
>    -  Right to security 
> 
>    -  Right to legal remedy

This is quite an interesting proposal, and one that I would not oppose. But maybe I could suggestion some granularity that is inspired by the current WHOIS discussions. Perhaps we can seek to provide attribution vis a vis responsible legal entities, and protection vis a vis natural persons?

This would for instance provide LEAs with a point of contact that they can approach with a warrant (for instance AS contact), but protect natural persons.

Would this make sense?

Cheers,

Niels

> 
> ===
> 
> Disclaimer: my views alone (and no intention to harm the security of others thru this communication) 
> 
> 
> _______________________________________________
> hrpc mailing list
> hrpc@irtf.org
> https://www.irtf.org/mailman/listinfo/hrpc
> 

-- 
Niels ten Oever
Researcher and PhD Candidate
DATACTIVE Research Group
University of Amsterdam

PGP fingerprint	   2458 0B70 5C4A FD8A 9488  
                   643A 0ED8 3F3A 468A C8B3