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

Bernard Aboba <> Tue, 28 January 2020 22:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3BC6D1200FE for <>; Tue, 28 Jan 2020 14:50:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_SCAM=1.999, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mwJ5ZcdIMnvO for <>; Tue, 28 Jan 2020 14:50:20 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::e34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DA53912006D for <>; Tue, 28 Jan 2020 14:50:19 -0800 (PST)
Received: by with SMTP id k188so9223746vsc.8 for <>; Tue, 28 Jan 2020 14:50:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pvZ1P5DZNl1I9cVSXz4OEbwS0CK10QqOU/MyprSpfSA=; b=idVaEIYwCtUg1Cq3IaU1ex6DUwo+/gI57FOD6vuGMMvPnXEYJFW3MeueAkglO8y/Mb 8donCNSQ1UbliZ91y4GrNFBDTcReNtYyx6MiQDy8T8OHo26xpSJ10fY+g97x1WsNUNgn zeVtrZMjBQzV3O7mEjWN27yOe6X6GZW2JC1lidz5oltYj8n+GRBlYoy8HRwaeSaYMOJA TwKW4jtSIJbxnBeLCwlpBw68Ysc+W2mLK680Z+e2YEjTXthYjnCe3wb18va9fAkGNGPZ 79eKcXnol337O4mGevyqwSwi1qRVHS4r8/O3GV/S2hOpEPibAR/gYEHGSSnM7NVvWOnb AZ2g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pvZ1P5DZNl1I9cVSXz4OEbwS0CK10QqOU/MyprSpfSA=; b=Smuqus3fFp7ZDL9jg1oRvZZQGe4o46+IMSDX6wQiB7S5kDJY0Y2kwIQeXYUiH0QHwR K8SlmoXQeRhTK04GdjhhmrEjzGxH96BZhMTtLo7heZCmsCCkMk9zSzFMcQO/buzTi7mm HI5birT74JbLjs/ouP6Skr/ZJZG+7rEWGioglj73v/9XFsMY9W9wilexNnITETWy0RDo bbhwpmSn5xf+il7hBRmYoSmTDsTtd7EE2ClHQbe/5r+XaLl2YbkJ3pEVL+T6mMnaAqeA avuZ9CfqX2pvGKr19+KOQdLWMudDl/mWBfxzKlA/zRJRyur0EDqPwvPBAAMjZvdYiNwj k1Iw==
X-Gm-Message-State: APjAAAWQLPmIpTLUt6J+BY9UFNpNQ0gcDP1mW86g0eKPwfVnytv4SJAV uCUxjan2A8fsrskG1CKid9qucvNMlY4uR44975vrjStO
X-Google-Smtp-Source: APXvYqyQNVpMsiVqbSKLjy6pBtaR3jEFUoLdnRj7mdc/TDbyetrSHiA3UvZX7c58hCRTb2nalJYVRFEwB9zCeiDsrV0=
X-Received: by 2002:a67:f1ca:: with SMTP id v10mr15299209vsm.180.1580251818630; Tue, 28 Jan 2020 14:50:18 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Bernard Aboba <>
Date: Tue, 28 Jan 2020 14:50:08 -0800
Message-ID: <>
To: Eliot Lear <>
Content-Type: multipart/alternative; boundary="0000000000004e21b9059d3b0c86"
Archived-At: <>
Subject: Re: [arch-d] [Model-t] Possible new IAB program on Internet trust model evolution
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 28 Jan 2020 22:50:22 -0000

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.

However, I do think that you're on to something important that is worth IAB

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

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

On Mon, Jan 27, 2020 at 10:44 PM Eliot Lear <>

> Hi Watson,
> On 28 Jan 2020, at 02:35, Watson Ladd <> wrote:
> On Sun, Jan 26, 2020 at 1:44 AM Eliot Lear <> wrote:
>>   Let’s look at three specific examples that I’ve mentioned:
>> 1.  Train signaling system needs to be audited both live and
>> retrospectively in the case of accidents.  This has to happen in such a way
>> that the auditor sees precisely what was sent by one endpoint and received
>> by the other.
>> 2.  The case of “parent doesn’t want Internet toy to send video of
>> child”, when the camera is undisclosed (it’s an analog to the privacy
>> analysis on Alexa[1] and the now infamous NEST episode[2]).
>> 3. CPAP machine or an AED/pace maker provide a control interface to the
>> doctor but the patient or his next of kin wants the data.
> I've got a few more examples from real life:
> 4: We need to see who is sending pictures of Winnie the Pooh.
> 5: We don't want pictures of the inside of our detention centers to appear
> online.
> 6: I want to see everyone's credit card number at the coffee shop I run.
> Any discussion of tapping network communications because endpoints can't
> be trusted needs to take these cases seriously.
> Absolutely.  What I am suggesting is a relatively new twist on an old
> problem(*).  It’s important to understand the economic and policy aspects
> of how/whether to avoid [4] and [5], how to avoid [6] while at the same
> time addressing use cases I mentioned.
> So… today’s new information comes courtesy of the EFF.
> Here we have yet another IoT device that, from at least one person’s
> perspective is invading home privacy.  And again, it is the device itself
> that is the threat.  In this case, it’s probably a more manageable threat,
> because one can simply not get a NEST.  Try not getting a CPAP machine.
> And this brings us around to what layer to solve the problem at.  Some of
> this may need to be dealt with at layer 9 rather than at lower layers.  We
> should have that discussion too.
> Increasingly corporate networks are moving away from network layer access
> controls and using user authentication over TLS, so-called BeyondCorp
> model, including checking endpoint posture through management.
> I don’t think this solves the railroad case.  Do you?  Just to clarify the
> example:
> According to their logs, two separate signals received  “set your lights
> to green” at the same time, causing two trains to crash into each other.
> According to the signal controller’s logs, it sent “set your lights to
> green” to only one signal.  What happened?
> All of the cases we are discussing have slightly different flavors of
> threats.  From an IAB program standpoint, the real question here is this:
> what are the architectural building blocks that are required?  Keep in
> mind, some of those blocks could be code and some could be policy.
> One goal should be code reuse. It is probably best that the people
> building the train signal *not* reinvent everything, but rather benefit
> as much as they can from the experience and results that you, EKR, and a
> great many other people have brought to society.
> Eliot
> (*) It’s also important to not fall into old tribal communication
> patterns, while recognizing the realities of the concerns raised by you,
> Watson, and me.
> _______________________________________________
> Architecture-discuss mailing list