Re: [arch-d] [Model-t] Possible new IAB program on Internet trust model evolution

Eliot Lear <lear@cisco.com> Wed, 29 January 2020 09:48 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 7380F12026E for <architecture-discuss@ietfa.amsl.com>; Wed, 29 Jan 2020 01:48:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-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, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 efKmXHgqHOuF for <architecture-discuss@ietfa.amsl.com>; Wed, 29 Jan 2020 01:48:36 -0800 (PST)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEEEB12081F for <architecture-discuss@ietf.org>; Wed, 29 Jan 2020 01:48:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9988; q=dns/txt; s=iport; t=1580291316; x=1581500916; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=afumTtU1ff+fMfKCgGo7KUZObPySDVgTD0fuDqnYhzc=; b=VVsduxouV7rPicGLwyuIpuvTxRqEYgWL8DEgC99QbGhQTLvOqJqKmAfi TMQsX4yXLWg3u9YydgcDwbVdipO2wQ0uV7rVlY3Z2J7UZ5wguXzW8VvOk Q6de/6z+0VCbbhvfHlU7rJ9pvKp0qL3BYja8+9GZo416SvU+7TCxI0MYH k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CrGACNVDFe/xbLJq1mHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgXsCgSOBcFQBIBIqhBSJA4d0JYlhiUyGEYF6CQEBAQwBAS8BAYR?= =?us-ascii?q?AAoJMOwMNAgMNAQEEAQEBAgEFBG2FQ4VeAQEBAQIBI1YFCwsYKgICITYGExQ?= =?us-ascii?q?HgwsBgkoDDiCrXnWBMoVKgk8NgiCBOAGMOYIAgTgMFIIeLj6CG4U+MoIsBI1?= =?us-ascii?q?YATKSGY4+MkSCQ4JMj0KEKRuWOoRFmWiMV4MuAgQGBQIVgXwDDIFYMxoIGxV?= =?us-ascii?q?lAYJBPhIYDY4pFxWOD0ADMI5HAQE?=
X-IronPort-AV: E=Sophos; i="5.70,377,1574121600"; d="scan'208,217"; a="22732074"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 Jan 2020 09:48:33 +0000
Received: from ams3-vpn-dhcp4134.cisco.com (ams3-vpn-dhcp4134.cisco.com [10.61.80.37]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 00T9mW5M019746 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 29 Jan 2020 09:48:33 GMT
From: Eliot Lear <lear@cisco.com>
Message-Id: <16390A67-B502-4278-B93E-2642025F356D@cisco.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_E6E548D7-8843-48BF-88A9-1E7BB8B41791"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\))
Date: Wed, 29 Jan 2020 10:48:32 +0100
In-Reply-To: <CAOW+2dvf6hhcCimis8Q0RUCtY_-ZkaoC6p6t-HpOj5K6Q6O08w@mail.gmail.com>
Cc: architecture-discuss@ietf.org, model-t@iab.org, Toerless Eckert <tte@cs.fau.de>
To: Bernard Aboba <bernard.aboba@gmail.com>
References: <E2D709DC-DD01-4946-B2F1-7EE0E101DEF0@piuha.net> <dff1c31e-44d4-6045-aaeb-03ac1e855200@gmail.com> <CABcZeBOYsP+SBNdLqc-wmyJAs1A+hvWbKud_XfvDgi9zJVMD+w@mail.gmail.com> <CA+9kkMDFm7nboqQY2OjNvmcWxs_30d_5NtBv8Nd1eLBnWKBaBw@mail.gmail.com> <6a1a019b-8666-269c-56ca-ebae4b69e9e8@huitema.net> <C7FDAD8F-D66A-4618-9F87-B1BB9CEA191B@cisco.com> <CABcZeBPKFEEDqQEGXZAD87n5cCsA75+uMGp-brq0JXBoW91LjQ@mail.gmail.com> <96A32815-C313-4C08-90FF-DDAFAD591287@cisco.com> <CACsn0ck9PDAOhZrbBZ7e4UVU7eNiSgrfVO7JL9zaYaX3if2WVw@mail.gmail.com> <DCE750AF-6439-4961-A4DA-ED855807F68E@cisco.com> <CAOW+2dvf6hhcCimis8Q0RUCtY_-ZkaoC6p6t-HpOj5K6Q6O08w@mail.gmail.com>
X-Mailer: Apple Mail (2.3608.40.2.2.4)
X-Outbound-SMTP-Client: 10.61.80.37, ams3-vpn-dhcp4134.cisco.com
X-Outbound-Node: aer-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/UKP-M2EOW3C7qfbF1p0dQmX8LYc>
Subject: Re: [arch-d] [Model-t] Possible new IAB program on Internet trust model evolution
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: Wed, 29 Jan 2020 09:48:38 -0000

Hi Bernard and thanks for your valuable thoughts.

> On 28 Jan 2020, at 23:50, Bernard Aboba <bernard.aboba@gmail.com> wrote:
> 
> Eliot --
> 
> The examples you describe are difficult to capture within protocol-specific threat models (RFC 3552) or privacy considerations (RFC 6973).  For practicality, those analyses need to maintain a narrow focus, yet at the same time we understand that systemic privacy and security issues can only be understood when analyzing the system that a protocol is embedded in.  As a result, even protocols that successfully address the original threat models can be the source of major systemic vulnerabilities. For example, we could not have expected the authors of RFC 1945 (HTTP 1.0) to have anticipated the security and privacy problems arising from today's social media implementations - some of which were discussed during the Internet Privacy Workshop summarized in RFC 6462. 

I really cannot say what, if any, protocol changes I would suggest at this point to handle some of the cases I mentioned.  Assuming there is interest in this approach, I would suggest a bit of a collection and a culling.

I want to address one related point: Joel doesn’t think the program should get up into layer 9 too much, and I would say that it would be necessary to do so to figure out where we as a community want to make some Lessiguesque law, and when perhaps we need to leave that to others, but see below.

> 
> However, I do think that you're on to something important that is worth IAB consideration. 
> 
> It strikes me that in a number of the examples you cite the "endpoint" is not acting in the interest of the "end user", at least in the sense described in draft-iab-for-the-users.  As was noted in Section 4.2:
> 
>    In contrast, the Internet of Things (IoT) has not yet seen the
>    emergence of a natural role for representing the needs of the end
>    user.  Perhaps as a result of this, that ecosystem and its users face
>    serious challenges.
> 
> For example, consider how some of the IoT behavior you describe might be handled within a permission model implemented in a browser or a mobile device: 
> 
> 1. Would a user grant permission to access to camera or microphone?   In the example of the device that did not advertise that it contained a microphone, presumably, the answer would be "no" (although the microphone was not initially enabled so perhaps permission might not have been requested). 
> 2. Would the user grant permission to access personal information such as location?  In the example of the device with embedded trackers, again the user would probably not have granted access to location and other data (although we know that location can easily be obtained in circumvention of browser or mobile device protections).
> 


Very well put.

I think that leads us into a bit of futuristic scenario planning about how that permission model would work, what the control points are, then how they interact, etc.  The L9 discussions come in the form, I think, of incentive modeling to address the for-the-users point.  But that’s for later.  For now, what are the problems?

To Toerless’ point:

> Yes, i think we can agree that we would like all Internet end-to-end
> transport must not even allow for a misconfigured option to use null
> encryption, but i think when TLS 1.3 was standardized, there should have
> been a better solution than to completely oppress the needs of those
> other use-cases.

And my suggestion is that we take three steps back before we even go there.  Let’s not treat this like an IETF working group, but pause and take deep breaths and work the problem space just a bit.

Eliot