Re: [hrpc] Human Rights Research Group Call on draft-irtf-hrpc-research-07

"Bless, Roland (TM)" <roland.bless@kit.edu> Tue, 10 January 2017 15:41 UTC

Return-Path: <roland.bless@kit.edu>
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 5E07D12950D for <hrpc@ietfa.amsl.com>; Tue, 10 Jan 2017 07:41:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no
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 6t3Xe3WPrt-Q for <hrpc@ietfa.amsl.com>; Tue, 10 Jan 2017 07:41:52 -0800 (PST)
Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (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 7D44F129507 for <hrpc@irtf.org>; Tue, 10 Jan 2017 07:41:52 -0800 (PST)
Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=i72vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 iface 141.3.10.81 id 1cQyYW-000277-5G for <hrpc@irtf.org>; Tue, 10 Jan 2017 16:41:48 +0100
Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id 0A35EB002B5 for <hrpc@irtf.org>; Tue, 10 Jan 2017 16:41:48 +0100 (CET)
References: <1ee78d09-fd33-1851-6786-5645f4833671@acm.org> <9c1dc523-7f1f-db40-efdf-5e08ccdd630d@kit.edu>
To: hrpc@irtf.org
From: "Bless, Roland (TM)" <roland.bless@kit.edu>
Organization: Institute of Telematics, Karlsruhe Institute of Technology
Message-ID: <1d010e09-7ad6-9b47-b871-4680f7aeb9a5@kit.edu>
Date: Tue, 10 Jan 2017 16:41:47 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <9c1dc523-7f1f-db40-efdf-5e08ccdd630d@kit.edu>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de)
X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1484062908.
Archived-At: <https://mailarchive.ietf.org/arch/msg/hrpc/NjtTyUksIkv4qASzUygpYior_Fg>
Subject: Re: [hrpc] Human Rights Research Group Call on draft-irtf-hrpc-research-07
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "niels@article19.org" <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, 10 Jan 2017 15:41:56 -0000

Hi,

> There are some inaccuracies with the vocabulary section and I have
> several comments for section 4. I'll come back to that later in more detail.

Here we go...
Since other work prevented me to follow the hrpc list closely in the
last weeks, I apologize for repeating some comments that others already
made.

Abstract:
---------
IMHO the abstract should not start with a "list of sections" it
provides. It should rather start with the main issue of providing
considerations on human rights in protocols (or protocol design),
comprising proposals for consideration guidelines, vocabulary,
and a description of the methodology as well as a coarse literature review.

Introduction:
-------------
I find it a bit confusing to directly start with citations without
setting the context first, so probably move the citations somewhere
into the text, where they fit.

In a broader sense, protocols touch also other values, not only
human rights. So probably, a short motivation should be given, why
this draft/RG concentrates on human rights.

While the draft talks a lot about human rights, it doesn't list
a few of them as examples (e.g., at least those used later in section
4). Therefore, I propose to extend the vocabulary and also define
"human rights" there (it's ok to list some of them and repeat the
references for further details...).

Typo: "This has led to an broad" -> "This has led to a broad"

"The purpose of the Internet to be a global network of networks that
provides unfettered connectivity to all users and for any content
[RFC1958]." -> I couldn't find this statement in RFC 1958.
(general comment: please be more accurate when you cite documents, this
also applies to several other places, esp. in the vocabulary, see below).
RFC 1958 talks about connectivity as a goal of the Internet
architecture, but doesn't mention "unfettered connectivity to all users
and for any content".

"Additionally, access to information gives people access to knowledge..."
-> probably qualify this by using "generally accessible information"
or "freely available information" (some information on the Internet
isn't freely accessible or available for all on purpose).

"In order to do this it is crucial that the rights impacts are clearly
documented in order to mitigate the potential harm in a proportional
way." -> I find this statement problematic.
Sometimes the impacts are complicated since several rights
may be affected at once. Moreover, how to actually balance between
conflicts isn't clear at all sometimes.
So I don't know what "mitigate the potential harm in a _proportional
way_" actually means nor how to achieve it...

Vocabulary:
-----------
"Authenticity" -> while other security terms are taken from RFC 4949,
this one isn't (any other reference for this particular definition?).
Usually Authenticity includes data integrity as defined
in RFC4949 (just stating that it is strongly linked with integrity
is IMHO a bit too weak).

Censorship isn't defined but used in the definition of Censorship
resistance.

Confidentiality: the definition isn't correct (unintended ->
unauthorized) and also isn't taken literally from RFC 4949 although
referenced... better replace it with the definition from RFC4949.

End-to-End:
- Typo "principal -> principle"
- This definition here mixes "end-to-end transparency" issues with
  the "end-to-end argument in systems design" (the Saltzer, Reed, Clark
  paper). I think it is indeed
  clearer to separate the two (see also
https://tools.ietf.org/html/rfc2775 and
https://tools.ietf.org/html/rfc4924).