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

Paul Wouters <paul@nohats.ca> Fri, 13 December 2019 14:21 UTC

Return-Path: <paul@nohats.ca>
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 73785120855 for <architecture-discuss@ietfa.amsl.com>; Fri, 13 Dec 2019 06:21:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 mHB-r2SBDGz4 for <architecture-discuss@ietfa.amsl.com>; Fri, 13 Dec 2019 06:21:47 -0800 (PST)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 AB5F5120154 for <architecture-discuss@ietf.org>; Fri, 13 Dec 2019 06:21:47 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 47ZCXT5GydzDRm; Fri, 13 Dec 2019 15:21:45 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1576246905; bh=O7gtYbXXTUQ9bIez7gt0pTF8GMCLKU5/Sr8dYslGtfQ=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=dXsSSNLxsiGObCbm5Lk1dOm/EMkazvPoSIWId5UoHKPUAnn0gmxKkmZ769rdqJ6oy ExrdNF5KcxGYBruO/I422gbq1X3b9JMbYqivd293ub79f8CeDiwwPR2NnAdN1mtKn5 SusVnsH82xRKum5KN7L22O7BaPqcD2AJYUtPIqmg=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id HsZRD5YHdOl2; Fri, 13 Dec 2019 15:21:44 +0100 (CET)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 13 Dec 2019 15:21:44 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 6CA266007ADD; Fri, 13 Dec 2019 09:21:43 -0500 (EST)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 688CE66AA8; Fri, 13 Dec 2019 09:21:43 -0500 (EST)
Date: Fri, 13 Dec 2019 09:21:43 -0500
From: Paul Wouters <paul@nohats.ca>
To: Eliot Lear <lear@cisco.com>
cc: Ted Lemon <mellon@fugue.com>, Vittorio Bertola <vittorio.bertola@open-xchange.com>, "hrpc@irtf.org" <hrpc@irtf.org>, architecture-discuss@ietf.org
In-Reply-To: <31473650-0872-4EFE-A99C-E3DD4CDBC700@cisco.com>
Message-ID: <alpine.LRH.2.21.1912130913480.8529@bofh.nohats.ca>
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> <31473650-0872-4EFE-A99C-E3DD4CDBC700@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/yLIi-V-pboXAcrS7p2ZfjVdGnwY>
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 14:21:49 -0000

On Fri, 13 Dec 2019, Eliot Lear wrote:

> It concerns me that Paul Wouters can take from this document that somehow enterprises do not address end user interests.

Your take on what I wrote seems misinterpreted.

IETF protocols deliver protections within their protocols for end users
(or: end to end communication). Whereas the enterprise tries to take
some of that away to provide its own set of protections for their
subset of users (called customers or employees). My point was that
while both the end-to-end and customer/employees targets are valid,
the latter should not come at the expense of the former. The latter
(presumbly) voluntarilly opt-in for the replacement of protection
mechanisms. Therefor, the end-to-end principle of all users should
never be compromised for the betterment of a subset of users.

> 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).

The problem I see here, is that this business has the tools to do what
it wants to its subset of worldwilde users of a protocol to do what it
deems is best. But it should still not be at the expense of global
endusers as a group. Do not weaken the protocol for this use case.

That is the core of the argument I see returning at IETF, from TLS 1.3
to DoH and in the past with weake or backdoored crypto desires. I
think this document does a good job ob describing what I tried
to summarize from my viewpoint above and in my previous email.

Paul