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

John Curran <jcurran@istaff.org> Sun, 09 June 2019 19:36 UTC

Return-Path: <jcurran@istaff.org>
X-Original-To: hrpc@ietfa.amsl.com
Delivered-To: hrpc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39E1D12002F for <hrpc@ietfa.amsl.com>; Sun, 9 Jun 2019 12:36:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outbound.mailhop.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O6kLqfa5E6w0 for <hrpc@ietfa.amsl.com>; Sun, 9 Jun 2019 12:36:46 -0700 (PDT)
Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6E8612009E for <hrpc@irtf.org>; Sun, 9 Jun 2019 12:36:46 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1560109005; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=tAZc3N3e2OONJ2Be5kO0G/+i0jc/Rn8XTSMZiGEHkRPZZjDg6AaoPT2FAl+Ao13DnKfLQ+tQPi7vX iQDMybKvj2gnqsGHn6T6gAsv9J6gXkITNXFZO9dTnD6MmOLyHnvZWKO95iR7FTdy9b5922dEOGknkY WuYMdPOcKD+6/MkzEYQFYpmsEtKRh6liIWG3q0V1Oe0MgSfYOGguC3NkErCNvpywAbYfhWIBiO4IYw 443fw82Rfm83pu4mMMmvRZ9pZlM+MyTCMJd99hKtD+MnCPYtHr5PYB68dE9c0Wku9g/68ah38QemWA uK+Mywpojbfnt1D+hVrugj0H/IvkVRg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=message-id:in-reply-to:to:references:date:subject:mime-version: content-transfer-encoding:content-type:from:dkim-signature:from; bh=BnsKH3YgmYH/JiEYeWqHrFYZfcUd7KMR4cQQnLcl9hs=; b=tJeEETxX+HTRvem9W4YVCwcREGpuQXJWtUY0G2apxMJDsJolgbYA1rHc1evlkN6R7+HYBeqtmVjXn gGpDqSGSpo4WJvftpdoEY8ON/V6Ge34mdGXYAQmjUr2/qXDgZVUU2FvTN2u/m/1HQgKkm0ulvEU3/h Yx9aHK+zrOvptm4R7eGgEPcP3Ki8VFca/xNu9oVPVq8IO5mXg85t7W7fQzTSFxLCLUDdHzVCrKkoFq w/TFzwoaaa/Yk/XVWy2GXV0VjAO6ypDtGsQgWynOfWIRYGnjwCH5XTVyATM6ijjWwzxPWp33saHyxz strDtxwAxRHNI8mKQMD+BlRjCUMZr3Q==
ARC-Authentication-Results: i=1; outbound3.ore.mailhop.org; spf=pass smtp.mailfrom=istaff.org smtp.remote-ip=96.241.220.148; dmarc=none header.from=istaff.org; arc=none header.oldest-pass=0;
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=message-id:in-reply-to:to:references:date:subject:mime-version: content-transfer-encoding:content-type:from:from; bh=BnsKH3YgmYH/JiEYeWqHrFYZfcUd7KMR4cQQnLcl9hs=; b=Y9i+bHTKQhZMsLQzZMnwKEZQGtwuoPstvHKgdMsUglENj6Fwm45cFY6+xAirQMSdgdGMmLCItKNgv Xl+d2C8fa7PRsp/MpMhRbs2F2NNEg3s6gINbOHN2IDP2sLA6DJdCCjV09JGJDspJtVh4Z5JZ4nrJnl 64bV9ZKLCSZ3wrz+jCqym/1U+UrCsEwrTX8cX5u/KOtVJcgdK9j/jAifmSj3Wl9FNr1k/cjcucW9Vu 3/zA3dNNQsLYjZvdsV2JiWItTZOxddeTqgAcljAjkDkZExyatbw4tU3eqx5idTHam0Diphs4NWEMSq 5O/Afd7RtAFrz+HklDekAqghiQDQOcg==
X-MHO-RoutePath: amN1cnJhbg==
X-MHO-User: e8ca397c-8aed-11e9-ba65-db796b3fb7af
X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information
X-Originating-IP: 96.241.220.148
X-Mail-Handler: DuoCircle Outbound SMTP
Received: from geode.istaff.org (unknown [96.241.220.148]) by outbound3.ore.mailhop.org (Halon) with ESMTPA id e8ca397c-8aed-11e9-ba65-db796b3fb7af; Sun, 09 Jun 2019 19:36:43 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by geode.istaff.org (Postfix) with ESMTP id A4C8A3BBFE60 for <hrpc@irtf.org>; Sun, 9 Jun 2019 15:36:42 -0400 (EDT)
X-Virus-Scanned: amavisd-new at istaff.org
Received: from geode.istaff.org ([127.0.0.1]) by localhost (geode.istaff.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OrKwYQkvIIRe for <hrpc@irtf.org>; Sun, 9 Jun 2019 15:36:40 -0400 (EDT)
Received: from [192.168.200.108] (c-69-255-129-19.hsd1.de.comcast.net [69.255.129.19]) by geode.istaff.org (Postfix) with ESMTPSA id 9205F3BBFE4B for <hrpc@irtf.org>; Sun, 9 Jun 2019 15:36:40 -0400 (EDT)
From: John Curran <jcurran@istaff.org>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Sun, 09 Jun 2019 15:36:39 -0400
References: <155989623088.20255.12181969220178709616@ietfa.amsl.com>
To: hrpc@irtf.org
In-Reply-To: <155989623088.20255.12181969220178709616@ietfa.amsl.com>
Message-Id: <C550D5BC-8062-4C58-8CEC-B82B2798C1D9@istaff.org>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/hrpc/R5Cywj2IxvwPefMk0EX0rbG2oco>
Subject: [hrpc] Protocol/Architecture consideration of Attribution & right of legal remedy (was: Re: I-D Action: draft-irtf-hrpc-guidelines-03.txt)
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "mail@nielstenoever.net" <hrpc.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/hrpc>, <mailto:hrpc-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/hrpc/>
List-Post: <mailto:hrpc@irtf.org>
List-Help: <mailto:hrpc-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/hrpc>, <mailto:hrpc-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sun, 09 Jun 2019 19:36:49 -0000

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

===

Disclaimer: my views alone (and no intention to harm the security of others thru this communication)