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

Watson Ladd <> Tue, 28 January 2020 01:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 91A033A0817 for <>; Mon, 27 Jan 2020 17:35:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.537
X-Spam-Status: No, score=-0.537 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HK_SCAM=1.56, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 i0Bd78kTkkdp for <>; Mon, 27 Jan 2020 17:35:45 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2A67A3A0819 for <>; Mon, 27 Jan 2020 17:35:44 -0800 (PST)
Received: by with SMTP id y6so13028818lji.0 for <>; Mon, 27 Jan 2020 17:35:44 -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=UvelYSjIpnaPKycH7toH7M87Th3xuvnu5gJSXm1WhBk=; b=Dj4r0QC+00QHhjNSXCubtTdDxZbndyVnzxc4rcMJU0oBqSPJXiAH/qFA0NDoFqI4kY GLRPd8i7hdmas1yDCw4ctYmokEFUZ1bFt0vXkY+e6lbI7nmBKUhnFbTAVJno+uiNzE2Q q4bbAP3TqQ3X8Ngeb9TNfdG4LqK+FhBq0FRT03gorwY3eCfk8KKEE6U8qtUIwrCFpOfp WULcrMjeKTkLu8YMqcqnrCqSkkbOzBCR3VIW7x1yykfMAdw/aoW3XD9kfbjxhMRlVZ43 6gVNHHfN3OAXfh+9+11T/gG6V0NjcPpSMxQdRe0HKwHsYZusQS7SbBRMSnxpZBg0NIqL MgCQ==
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=UvelYSjIpnaPKycH7toH7M87Th3xuvnu5gJSXm1WhBk=; b=IUth5RBlL00ooBSHSWldJe2R+Ir6D7HIq5GZqncepJ0uZownx47Yql9/1uiErmh4cc w+wwNrz8ulVpUBCN3KxcI3HPfNSGOUZ9/k33vBqf/Q+iWxOVVG6cVOVmqc6I02WL5aGB 7QuHU3Se22bfh/LCbVUDdVAP5jptTOopEFRuOJpvU+WnV3gBl0ncb4pxrgvMOwfzhrgg h4g8teorJ+AS+wwhf5sZWLGD8o7bqzI/32UqFBIyismmptNoaPCTAB1Sphnsc5AkLtAc N7yiIyhuTilZ7oc+XZXhUfiYuXfSth6KmKZOiU0xABIDbIXYf5VmMehI7GeeoHBNHrjn cbmw==
X-Gm-Message-State: APjAAAX+He0scQ+s53fE8Xugk2x5sfG0TFDX+x4DmK0VkeStU73ZwznM IXPCTO7ruk6Rr36rxXKHevVKIzWnN8ccG8cCnG0=
X-Google-Smtp-Source: APXvYqxeo+0o86yEcY2q3va4CRtspX+Us8RY872iIXjq2K6uRa6ZcvlFhq0Nm3fH6tEkxiC9OpugcJb2eTjMXq/Vw4c=
X-Received: by 2002:a2e:98ca:: with SMTP id s10mr11937208ljj.160.1580175343022; Mon, 27 Jan 2020 17:35:43 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Watson Ladd <>
Date: Mon, 27 Jan 2020 17:35:31 -0800
Message-ID: <>
To: Eliot Lear <>
Cc: Eric Rescorla <>,,
Content-Type: multipart/alternative; boundary="00000000000000f75f059d293e4b"
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 01:35:48 -0000

On Sun, Jan 26, 2020 at 1:44 AM Eliot Lear <> wrote:

> Hi Eric,
> I apologize for the length of this missive.  I’ve included examples that
> are either from real life or plausible to the point of inevitability.
> On 26 Jan 2020, at 08:36, Eric Rescorla <> wrote:
> It's probably useful to put the text in 3552 in context, which was
> primarily about designing COMSEC protocols. Our ability to build two party
> protocols which survive one of the parties being compromised is fairly
> limited.
> Indeed.
> We *do* have some praxis for building N party protocols which gracefully
> degrade when some of the nodes are compromised (for instance consensus
> protocols). Of course, the exact properties of those protocols can be
> difficult to succinctly state.
> They are, and they are hard to build, and they have their own failure
> modes.(*). But I really wasn’t going there, at least not directly.  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

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.

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.

Each example has a slightly different threat model, in addition to what you
> stated in 3552. In the first case, we add mistakes on the part of the
> operator (certainly the most common at this point**), and endpoint
> compromises.  In the second case, it is the manufacturer themselves that is
> the threat, for failing to have disclosed what they are doing.
> The third case is more difficult.  Let’s say a patient died.  Did the
> patient die (a) of natural causes, (b) due to a mistake made by the patient
> or a care giver at home, (c) due to a mistake made by the healthcare
> professional on the other end, or (d) due to an cyberattack?  It may be
> impossible for the next of kin to know if there is no network audit
> capability.  Yes, this is a messy case, which makes it a good one to
> explore.
> The program can explore COMSEC, UX, and higher level issues as well, like
> economics.  That latter one is actually important because if in the end the
> use cases above are going to get trumped by economics on the part of
> manufacturers, what’s the point of specifying mechanism?   This also goes
> to another point about which the IAB has had concern: concentration and
> control points.  That can be explored as well here. This does look to relax
> the assumption you laid down in 3552 about endpoints, but I don’t think it
> dramatically changes things.
> Also, when you wrote 3552, there was really only the theoretical notion of
> a cyberwar, ruling out attacks with infinite or near infinite resources.
> That’s now an every day reality.  In RFC 7958, we sort of ruled them back
> in, but I think it’s worth exploring a bit more what that means.  A program
> for that is a *very* good idea.
> I'm not quite sure I understand what you mean when you say "They are the
> source of just about all compromise attacks." I'm not saying it's not true,
> but perhaps you could elaborate.
> With apologies, I was shamelessly stating the obvious: the vast source of
> bugs are on end devices, not because middle boxes are better designed (some
> are, some aren’t), but because of sheer numbers.  Well, if endpoints are
> where the problems are, that’s where we need to spend time as a community.
> Eliot
> (*) My favorite example of a consensus protocol that had “good intentions"
> was BSD timed.  “It was a dark and stormy night”, when every participant
> had an unstable ticker in a different way, leading to time storms.
> (**) For a very interesting read for anyone interested in IoT, I highly
> recommend “Famous British Railway Disasters, Ian Allan Pub, 2000.
> [1] Malkin, et. al., “Privacy Attitudes Toward Smark Speaker Users”,
> Proceedings of Privacy Enhancing Technologies,  2019.
> [2]
> --
> Model-t mailing list