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

[Vittorio Bertola <[e-mail]>]

Il 26/01/2020 10:44 Eliot Lear <[e-mail]> ha scritto:

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.

Part of the issue is, when you have to write "security considerations", what do you mean by "security". If that means "security of the protocol", I can see why you end up with a theoretical approach that defines the security of the endpoints as out of scope. However, if that means "security of the applications that will be built over the protocol", or "security of the users of the protocol", and if security includes privacy and data protection (or even human rights, as the people in HRPC would argue), then the scope becomes much broader. Given the desired focus on prioritizing end-user needs, the meaning should be the latter.

In that case, in the almost 20 years that have passed since RFC 3552, the scenario has changed significantly. For example, 20 years ago end-users were, at least in theory, fully in control of what ran on their endpoints, which basically consisted of personal computers; nowadays, most end-users access the Internet via smartphones, where their control is much more limited - and let alone IoT devices; both smartphones and IoT devices are categories of endpoints that did not exist at the time. 20 years ago there was no "cloud" or "edge computing", and even if the cloud is just someone else's computer, still the location of personal information over the network has significantly changed. 20 years ago the Internet was the Internet, i.e. a permissionless innovation network of networks where lots of people produced content and services even on a very small scale; nowadays, apart from email and the web, many of the most popular services consist of walled gardens, and even network infrastructure is remarkably centralised, not in topological terms but in terms of ownership and control.

I think that it would be good to discuss how these things impact the security of the user, and how they should be considered when writing new protocols. Perhaps, after the discussion, we could conclude that they do not affect protocol design. But I think that in some cases they could, and so the discussion would be useful.

--

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[e-mail] 
Office @ Via Treviso 12, 10144 Torino, Italy