Re: [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> Tue, 11 June 2019 15:43 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 02395120025 for <hrpc@ietfa.amsl.com>; Tue, 11 Jun 2019 08:43:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 0hxlqvlS2tjk for <hrpc@ietfa.amsl.com>; Tue, 11 Jun 2019 08:43:54 -0700 (PDT)
Received: from outbound2r.ore.mailhop.org (outbound2r.ore.mailhop.org [54.200.129.228]) (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 31B2D12013D for <hrpc@irtf.org>; Tue, 11 Jun 2019 08:43:53 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1560267833; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=FGj7/HctMIbppqohrDsCIBKQWWI7CkU9OxqPGFPfTGaG3EDG+vOZjdm2BVmNiz4/+uT7rzdwZJtl4 +k4gdO357jsi6HKgVk85PXp2RTfnJmZMANNhx07xElNP9YmqOBwXm59Zl+V/e/8Vp4CYBT2mKPDOJ2 WQg10uyoKLmeeFBIwPX6LMsU4+eu/VqfC6accMJRwgRQRWz6poVTA1cX7QsExIaB31dXGhq6XKiRyS Hq/Va4rVnNNBj0+rc8RZ0cZxkCImeDAL02VrdBv4vGahz+4Z3Btthp5m+im7auIiIvp2yNRCLybrhQ 6sMCPG1YcWkdGW3pAgX+Ap8aY5CpSoQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=references:to:cc:in-reply-to:date:subject:mime-version:content-type: message-id:from:dkim-signature:from; bh=E71eA4yL1/TE6BRhY+pfYEbNziar5d2R+aFI3XtvK50=; b=lysGZQTagpHEnhseL0lwOMtbXRAFDnOA2hCZ3xfvjIKXqFkEN7spvQkKnfbTliUnSgd80uSLeYs10 veEtxHv5bCOlluD6RsfhmTNVtiyaur9eKxgGI9wgCo571GGot/7Vcps9IdplxJYpv1xtM6x7/y+6LF +dGujwp5KRnECiIBJrERGOae8cZS8kqvIbSs6eE5Y5Z6of5D5/f6LqA+xZiNPelrFJf2Kd876DbVIJ E07Gwp4rZEf0m4DAzrVQjuUBCZdsyOOUa36FNiwH8YLS6oxm8ACwp6nTAahFRXpaavvMBvXkjavlYL QlbCny0+sS/Bfoq60vbCx68yZ+UiMlg==
ARC-Authentication-Results: i=1; outbound4.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=references:to:cc:in-reply-to:date:subject:mime-version:content-type: message-id:from:from; bh=E71eA4yL1/TE6BRhY+pfYEbNziar5d2R+aFI3XtvK50=; b=dBM59FNOcYPNkB66HsgQGUuQLeeD5BMpzBG7Uqraub1qN2QqsCNGVty1T/9OhfQN7ofs8r6UD6a7p j+cEIE8MWFEhepFywhfY+UiQJrwpNbY2A6XYItqu3eI15TF6kTCsf3H16iB8uOq7Tr66yEZZYdO1Pd oS2S5ydE+8s8pZ2GaDW/ufacEn+7QEJJOp1AoitoGVsY/bRPV3JdToPOVfyKt1OzHsVjmGGu0GwcU6 fMOK6CyKa9HLxX0P9D/CHng1Vn0o+zp4P/yZSXH29u8Wv96xImGt2az6naYRCVPbZPSDXPg02CpoWx ygobjNYuHq4uwW2zn8N16ciOlGaOn3w==
X-MHO-RoutePath: amN1cnJhbg==
X-MHO-User: b491bb1f-8c5f-11e9-b39a-9d2c53d3dedb
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 outbound4.ore.mailhop.org (Halon) with ESMTPA id b491bb1f-8c5f-11e9-b39a-9d2c53d3dedb; Tue, 11 Jun 2019 15:43:51 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by geode.istaff.org (Postfix) with ESMTP id D48733BD95DD; Tue, 11 Jun 2019 11:43:48 -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 uATxNhoRLKk6; Tue, 11 Jun 2019 11:43:47 -0400 (EDT)
Received: from [172.20.0.75] (unknown [65.216.233.162]) by geode.istaff.org (Postfix) with ESMTPSA id BFE423BD95BE; Tue, 11 Jun 2019 11:43:46 -0400 (EDT)
From: John Curran <jcurran@istaff.org>
Message-Id: <B8D9823F-2D42-42DF-AE8A-6E67532DA4D1@istaff.org>
Content-Type: multipart/alternative; boundary="Apple-Mail=_651CB97F-03D8-4807-98CC-2E02B94F61ED"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Tue, 11 Jun 2019 11:43:45 -0400
In-Reply-To: <71b7350e-cb75-aba1-1717-50d1069531b1@nielstenoever.net>
Cc: hrpc@irtf.org
To: Niels ten Oever <mail@nielstenoever.net>
References: <155989623088.20255.12181969220178709616@ietfa.amsl.com> <C550D5BC-8062-4C58-8CEC-B82B2798C1D9@istaff.org> <71b7350e-cb75-aba1-1717-50d1069531b1@nielstenoever.net>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/hrpc/a8aD8WySZc_vTp-e0tSa5CaDWBM>
Subject: Re: [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: Tue, 11 Jun 2019 15:43:58 -0000

On 10 Jun 2019, at 10:46 AM, Niels ten Oever <mail@nielstenoever.net> wrote:
>> ...
>> 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?

Neils - 

A very interesting question…  I was not so much advocating for a particular set of norms regarding attribution, but simply some recognition that protocol/architecture design decisions can impact the ability to attribute communications and thus can hinder exercise of rights (such as legal remedy) when attribution is necessary for exercise of same. 

While I think that much more dialogue would be necessary to understand if there is indeed an widely-accepted set of norm that should be used for protocol assessment in this area, your point regarding legal entity attribution vs natural persons is well taken, and might be raised in the mind of a potential protocol designer (or reviewer) by the addition of an additional question, as follows:

  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? 
  If attribution to a natural person is not available, does the protocol/architecture
  provide any mechanisms for obtaining contact information for a legal entity 
  responsible (or representing those responsible) for the communication?

This raises the very pragmatic point that attribution to natural persons is not necessarily a 
desirable outcome, but that some consideration of alternative mechanisms for attribution 
may still facilitate exercise of the "legal remedy" human right.

Thoughts?
/John

p.s. (Disclaimer: my views alone - no one else is foolish enough to claim them! ;-)