Re: [arch-d] [hrpc] New Version Notification for draft-iab-for-the-users-01.txt

Eliot Lear <lear@cisco.com> Fri, 13 December 2019 08:39 UTC

Return-Path: <lear@cisco.com>
X-Original-To: architecture-discuss@ietfa.amsl.com
Delivered-To: architecture-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E372F1200EF for <architecture-discuss@ietfa.amsl.com>; Fri, 13 Dec 2019 00:39:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 IsNC2sGPR0Wz for <architecture-discuss@ietfa.amsl.com>; Fri, 13 Dec 2019 00:39:16 -0800 (PST)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93E2812008C for <architecture-discuss@ietf.org>; Fri, 13 Dec 2019 00:39:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18023; q=dns/txt; s=iport; t=1576226355; x=1577435955; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=6ekeviGWh8c3lWkhJhtdsCt8Cvc3UknESI36m360GOY=; b=Mnpcxsiw7dReGfAN3W9SAgPvMvZipYUmb5ZycsWVbqbpnMBM2MV2dZ/1 T5Bo4hvyFYHLwFqJvxjPMXHKXrX6qgog9reUzEw6ijyslsNbK18EXAH5B crlBTqGP6Qwu5qbvU+qtFwAptLy+O8PcFkzC+mojxk5Hlfv4zTPqTwOHv 0=;
X-Files: signature.asc : 488
X-IPAS-Result: =?us-ascii?q?A0D+AADpTfNd/xbLJq1lGwEBAQEBAQEFAQEBEQEBAwMBA?= =?us-ascii?q?QGBfoF0gW0gEiqEA4kDiA0lgQGSI4YkgWcCBwEBAQkDAQEvAQGEQAKCLjgTA?= =?us-ascii?q?gMBAQEDAgMBAQEBBAEBAQIBBQRthUOFXgEBAQECASNUAgULCw4EBhUVAgJJD?= =?us-ascii?q?gYTFAuDAwGCVyCsKXWBMoVPhHAQgTaBU4pfggCBEScMFIIXNT6EBAkgW4JRM?= =?us-ascii?q?oIsBI0WiW2XbII6gjyBGYJGhjyJIgIZgkKHdoQahy+EQKVlgyMCBAYFAhWBa?= =?us-ascii?q?SI+gRozGggbFWUBgVloPhIRFFaMSBeBBAEHjRhAAzCPO2ABAQ?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.69,195,1571702400"; d="asc'?scan'208,217";a="20290412"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 13 Dec 2019 08:39:13 +0000
Received: from [10.61.204.232] ([10.61.204.232]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id xBD8dBhU011125 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 13 Dec 2019 08:39:11 GMT
From: Eliot Lear <lear@cisco.com>
Message-Id: <31473650-0872-4EFE-A99C-E3DD4CDBC700@cisco.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_470350DF-176D-4187-AFA5-D3C21E30A0AB"; protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\))
Date: Fri, 13 Dec 2019 09:39:10 +0100
In-Reply-To: <4A034991-E5C8-4797-B6BF-9484BB2FA614@fugue.com>
Cc: Vittorio Bertola <vittorio.bertola@open-xchange.com>, "hrpc@irtf.org" <hrpc@irtf.org>, architecture-discuss@ietf.org
To: Ted Lemon <mellon@fugue.com>
References: <157403781873.6404.6154827441040413193.idtracker@ietfa.amsl.com> <01246A3C-31EC-4B7B-841D-F799EEFADCB8@mnot.net> <227662299.12784.1575991106819@appsuite-gw2.open-xchange.com> <C74D5288-709B-46E3-B9F9-4FDE0234C451@fugue.com> <429195684.13066.1575996064551@appsuite-gw2.open-xchange.com> <0C729385-1361-460C-9C16-E1BE1680A3E6@fugue.com> <1100636076.15285.1576072588087@appsuite-gw2.open-xchange.com> <4A034991-E5C8-4797-B6BF-9484BB2FA614@fugue.com>
X-Mailer: Apple Mail (2.3608.40.2.2.4)
X-Outbound-SMTP-Client: 10.61.204.232, [10.61.204.232]
X-Outbound-Node: aer-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/-5IT6kk8whabH2Yxga_Gur5l5yQ>
Subject: Re: [arch-d] [hrpc] New Version Notification for draft-iab-for-the-users-01.txt
X-BeenThere: architecture-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <architecture-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/architecture-discuss/>
List-Post: <mailto:architecture-discuss@ietf.org>
List-Help: <mailto:architecture-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Dec 2019 08:39:19 -0000

Hi Ted, Vittorio, and others,

I am attempting to consolidate this thread with any discussion that might take place on architecture-discuss (thus the CC), in large part because this isn’t simply related to human rights, as we generally think of them.  I apologize for the length of this note.

&TLDR; the draft needs to go a little slower on recommendations, and should focus more on raising the issues for discussion within our community, which are complex, as I will get into below.

Mark and the IAB have taken on a very difficult task, which is to establish some sort of priority for end users.  The dialog in the draft has shifted over time, and it is often difficult to understand precisely what the practical implications of the recommendations are intended to be.  In the latest revision, Section 4 is expanded to really delve into the nature of harm, and how we should consider harm.  But there are few examples, leading to a point where it is difficult to understand the implications of what is being said.  I do like the economic incentive discussion, but I’m not sure whether it is broadly applicable.  That should get developed a bit more.

It concerns me that Paul Wouters can take from this document that somehow enterprises do not address end user interests.  The example I always give is that of a business who has a regulatory requirement to avoid leaking PII.  There are all sorts of toolsets that MITM communications in order to protect the privacy of account holders.  I think it would be useful for the draft to address this example as a bit of a case study.  One can reasonably argue that an explicit proxy mechanism on at least one side of a communication provides for this, but it begins to encroach on the so-called “end-to-end” views (I put that in quotes because the end-to-end model is often misused in these sorts of discussions).

I really like the comparison between the web and IoT.  I would go further: some of the very same technology that is used to protect users on the web may in fact be harmful to users when employed by IoT.  I’ll expand on this below.

The most difficult part of the draft remains who gets to decide what is in the interest of end users.  IMHO whether it’s governments, NGOs, or whoever, there is no way anyone can claim that mantel.  The best we have is rough consensus and running code, guided by whatever input participants bring to the table.

I would suggest that the IAB go a bit slower with recommendations, and focus more on discussion, which is quite valuable.  It’s okay not to have all the answers, but it may be just a bit too early to make strong recommendation to the IETF because we do not yet see the whole board.  I could definitely see this document being revised in an almost bi-annual basis, given how fast the state of the art is moving.

Please see below for more:


> On 11 Dec 2019, at 18:03, Ted Lemon <mellon@fugue.com> wrote:
> 
> 
> So e.g. if we were to abandon the end-to-end principle, or advocate blocking protocols by default, that would be against the user’s interests.   If we were to advocate censorship, that would be against the users’ interests.   This is clear, because an act of censorship necessarily implies that something the user wanted to do, the user can’t do.   That’s acting against the user’s interests.

As we apply these principles, one person’s censorship is another person’s privacy control, as I discussed above and will again below, depending on how specific mechanisms are deployed.

> Another example of the user’s interest is the user’s interest in privacy.  You will not find a user out there who doesn’t care about their own privacy.

Professor Serge Egelman at ICSI has delved deeply into this, and what he has found is that people are easily willing to trade off privacy for convenience, and we know this to be the case with the Amazon Echo.  But they are quite a bit more reticent when they learn that most processing goes on in the cloud, or that other people are listening, or when it is their children or guests that are being recorded. .  This has ramifications for the IETF in as much as our mechanisms are used to enable end-to-end communication between Amazon and the home.  OTOH, exactly how much information a service keeps once they have it is not something this organization can impact.

Complicating matters, privacy cannot be the only concern.  Let’s say that a law was passed that required some local processing to address privacy concerns.  No matter how you slice it, that harms the environment, requiring more power usage, more memory, and more CPU, that eventually generates more e-Waste.  If you missed that, it’s an argument in favor of end-to-end encryption, but against privacy protections in our protocol suite.

Looking at an industrial IOT example, the user may not be typing on the interface that controls electrical power or manages a dam, but this may have far more impact to individuals than their information being captured by hackers.  How does auditing occur when we cannot reasonably trust that an end device is secure?  The draft seems to recognize this challenge, but I’m not sure that’s reflected in recommendations.  And to just add fuel to the dumpster fire, there is plenty of PII mixed in at certain points in some industrial environments.

Given the above examples, one could reasonably argue that we should be developing 3rd party authorization models for encryption to protect both safety and privacy.  But if we do so, would that cause more harm than good when dealing with bad actor governments?  I can’t answer that, and anyone who can is demonstrating hubris.  The draft can be misinterpreted, I think, to say, “if one person benefits and another person is harmed, then do nothing”.  Lives are put at risk either way, and while looking at the whole board is hard, we have a responsibility to do so to produce least harm, assuming we are well suited to even make a call.

> You may find users who would like to violate other user’s [sic] privacy,

I hope you will be pleased to learn that at least some research (not just Egelman’s) shows that people generally don’t like doing this, and in fact they won’t sell off other people’s information.  On the other hand, you and I have a mutual friend who got royally miffed when I drop shipped to him a gift off of the web.  That showed my ignorance at the time that there was even a privacy concern to be had.  And so it is not a matter of liking or not liking but understanding when that violation is occurring.  Your point about transparency is very apt, although the use of “online service provider” can be ambiguously interpreted: when we got into this, people in this organization viewed telcos as a big threat.  The world has really changed since then, no?

Eliot