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

[Watson Ladd <[e-mail]>]

On Sun, Jan 26, 2020 at 1:44 AM Eliot Lear <[e-mail]> 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 <[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.
>

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.

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.
> 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/
> --
> Model-t mailing list
> [e-mail]
> https://www.iab.org/mailman/listinfo/model-t
>