[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)
- [hrpc] I-D Action: draft-irtf-hrpc-guidelines-03.… internet-drafts
- Re: [hrpc] I-D Action: draft-irtf-hrpc-guidelines… Gurshabad Grover
- [hrpc] Protocol/Architecture consideration of Att… John Curran
- Re: [hrpc] Protocol/Architecture consideration of… Niels ten Oever
- Re: [hrpc] Protocol/Architecture consideration of… John Curran
- Re: [hrpc] Protocol/Architecture consideration of… Amelia Andersdotter
- Re: [hrpc] Protocol/Architecture consideration of… Niels ten Oever
- Re: [hrpc] Protocol/Architecture consideration of… John Curran
- Re: [hrpc] Protocol/Architecture consideration of… farzaneh badii
- Re: [hrpc] Protocol/Architecture consideration of… John Curran
- Re: [hrpc] Protocol/Architecture consideration of… Ted Lemon
- Re: [hrpc] Protocol/Architecture consideration of… farzaneh badii
- Re: [hrpc] Protocol/Architecture consideration of… farzaneh badii
- Re: [hrpc] Protocol/Architecture consideration of… John Curran
- Re: [hrpc] Protocol/Architecture consideration of… John Curran
- Re: [hrpc] Protocol/Architecture consideration of… bzs
- Re: [hrpc] Protocol/Architecture consideration of… Pranesh Prakash