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

[Eliot Lear <[e-mail]>]

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/