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

[Guntur Wiseno Putra <[e-mail]>]

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

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

(2) https://www.rfc-editor.org/info/rfc2316;
https://www.rfc-editor.org/info/rfc3552


(3) The ITU of the UN report “Fast-forward Progress: Leveraging tech to
achieve the global goals”
https://www.itu.int/en/sustainable-world/Documents/Fast-forward_progress_report_414709%20FINAL.pdf

2019 ISOC Global Internet Report "Consolidation in the Internet Economy"
https://future.internetsociety.org/2019/wp-content/uploads/sites/2/2019/04/InternetSociety-GlobalInternetReport-ConsolidationintheInternetEconomy.pdf



Regard,
Guntur Wiseno Putra


Pada Minggu, 26 Januari 2020, Eliot Lear <[e-mail]> 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 <[e-mail]> 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.
> https://www.amazon.com/British-Railway-Disasters/dp/0711024707
> [1] Malkin, et. al., “Privacy Attitudes Toward Smark Speaker Users”,
> Proceedings of Privacy Enhancing Technologies,  2019.
> [2] https://arstechnica.com/gadgets/2019/02/googles-nest-
> security-system-shipped-with-a-secret-microphone/
>