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

Guntur Wiseno Putra <> Sun, 26 January 2020 13:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 13BBB12006D for <>; Sun, 26 Jan 2020 05:05:55 -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 E9g2wnqlrwAF for <>; Sun, 26 Jan 2020 05:05:53 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::32a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3D475120041 for <>; Sun, 26 Jan 2020 05:05:53 -0800 (PST)
Received: by with SMTP id i6so2048175otr.7 for <>; Sun, 26 Jan 2020 05:05:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ss5xAP5CgqNU5svEZ4fcsdryAr555dl+LZvYEUVD5po=; b=nMAFiyUNizlyqKyE0fBUXsMhuGa2DYD63BCHrsC8hQcfiVWSqjsVLC47NybDbb6IGd YO/VXl/9grJoiMosMehqdSr/+0YSh08Hs5r6HX53BhjACoIq6RWh4j4y61nm8xT2YObK VonnB1Xy1qayYkI/fqyG/Voxc9Z/Z7Kk8tArlH20+0zg8SAEFcSmVV7RF8Tkrl3Mz/rE oCmCk2LpsWypd7UMF/Omc/yEwYnX1rLSb8p5VtIHsdC1wSUsOP3sCE916AdPOFY5g7KU 3vv77nFw7jytgQQTO5ktuq/uawYM6zInALZgeoQnyHeVmuKeJZUk1tt7yRCMES02bVZ9 Yd/A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ss5xAP5CgqNU5svEZ4fcsdryAr555dl+LZvYEUVD5po=; b=KIXuPLYBQeJGKyTM9WZjub19/zC5vvdzD2TpgyIA7+EsLyUH0EUGX6lr+aWrDutox9 M15KWYIOCdOmSpD7byvrn06/WNtG5Ue01SBTiu9KGww+6U+Em2tnjWjwQ0rJrFyXAKJC DqPC51mkawZCcVWQrHkLcqdksKgyfN2vyMbCI8VWHboX8BlT/vcA2UFKVTMLIj+L+rOO 3uJhWfG6FI/7lsRC8FfWbpmt0gN7O7NnkKJHhArBLdF2I5+Yf1XnnjotU0dZMqRMaIu9 pqFheUgdspNj+TETU2BnmWYZuW4OYrlYCTGAMuHQv62f+/LuPRH2hVUgD/+hc1OASsiT 88LQ==
X-Gm-Message-State: APjAAAW3WfQSezHKguFrT0CN6p+1wEEJukkcNt+ySqt7ckikxpmXjGP9 2StTR5KvcHlCbq5S4SJD7eEAjePabZNJod7l64o=
X-Google-Smtp-Source: APXvYqz3Zvz2S8nAVmCqvS3PgZ1oMvIelImiHAbX2zJL0hBO13JObEGTIwihrq6IjPpei85ttJEg9YR7cAGSKTqoOdc=
X-Received: by 2002:a9d:6c52:: with SMTP id g18mr9322339otq.356.1580043952555; Sun, 26 Jan 2020 05:05:52 -0800 (PST)
MIME-Version: 1.0
Received: by 2002:a05:6830:1155:0:0:0:0 with HTTP; Sun, 26 Jan 2020 05:05:51 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
From: Guntur Wiseno Putra <>
Date: Sun, 26 Jan 2020 20:05:51 +0700
Message-ID: <>
To: Eliot Lear <>
Cc: Eric Rescorla <>, "" <>, "" <>
Content-Type: multipart/alternative; boundary="000000000000858ada059d0aa6e7"
Archived-At: <>
Subject: Re: [arch-d] 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: Sun, 26 Jan 2020 13:05:55 -0000

Dear architecture-discuss,

Networks of Interests: Trusts and Distrusts...?

In trying to follow the fluxes of the discussion, I begin with such basic
understandings below:

Networks of Interests: Trust and Distrust...

- when the interests are understood by either/all parties involved there
are (networks of) trusts.

- when the interests are not understood/accepted by either/all parties
involved there are (networks of) suspicions/threats/distrusts.

For the Internet:

As it is about networks of computers, of communications, so it is about
identifying  critical points of security: those threats and trusts --actual
and potential (1)

Two levels/layers to consider of analyzing the securities of the networks
of communications: technical architecture --which is about design
environment, (about "arstechnica"?)-- and the architecture's deployment

RFC 2316 and 3552 is considered as they are references of information and
best current practice of the Internet engineering (2).

The ITU of the UN report "Leveraging Tech..." and the Internet Society
Report "Consolidation in the Internet Economy" as kinds of analytical tools
to mapping a context (of problems, thus about real social conditions). (3)

(1) The identifications depends on interpretations and evaluations
(approaches and perspectives).


(3) The ITU of the UN report “Fast-forward Progress: Leveraging tech to
achieve the global goals”

2019 ISOC Global Internet Report "Consolidation in the Internet Economy"

Guntur Wiseno Putra

Pada Minggu, 26 Januari 2020, Eliot Lear <> menulis:

> 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.
> 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]
> security-system-shipped-with-a-secret-microphone/