Re: [Model-t] Review of draft-thomson-tmi

[Vittorio Bertola <[e-mail]>]

> Il 07/12/2021 00:34 Jari Arkko <[e-mail]> ha scritto:
> 
> 
> Hi,
> 
> I wanted to review this draft in preparation for tomorrow’s call. (Hopefully we will also have others doing the same on this and other drafts!)
> 
In the call we did not really get to the point of discussing this document, but I have two general comments on it that I would like to provide, and that also provide my perspective on the work we need to do.

The first comment is that to me the document reads as two separate parts, where the latter does not logically descend from the former. The first part (2-8) discusses what intermediation is, when it is good and when it is bad. It recognizes in several points, even with examples, that intermediation can be a positive thing and can be used for positive purposes. Then, abruptly, recommendations start and they are all about avoiding intermediation at all costs. The recommendations do make sense in many cases - e.g. designing things rather as services that can be authenticated and interrogated separately - but first of all a protocol designer should analyse how intermediation could happen, whether it is more likely to be good or bad, and whether it makes sense to put effort into making it harder or easier; then, if the answer is "harder", recommendations may follow.

The second and more general comment, which does not just apply to this document but more or less to the entire threat modeling work of the IETF until now, is that there is a permanent confusion of planes when discussing threats. Let's take the very definition at the start of section 2:

"A protocol intermediary is an element that participates in communications. An intermediary is not the primary initiator or recipient of communications, but instead acts to facilitate communications."

Now, if you consider the "communication" on the technical, network plane, we are indeed talking about "protocol intermediaries" that interject themselves in a communication that starts from the network interface of the originating user's device, and ends at the network interface of the destination user's device (or of the server providing the service). Then you can discuss the privacy and security of this specific communication under the current RFC 3552 assumptions, i.e. that what is outside of it is not adversarial and has not been compromised.

But if you want to make an analysis or claims about the privacy or the security of the communication from the end user(')s(') point of view, then things look rather different. An "intermediary" (without the "protocol" qualification) is basically everything that sits between the originating user's fingers and screen and the destination user's fingers and screen. The software on the user's device that acquires the user's keystrokes, formats them as protocol messages and sends them on is a "protocol endpoint" but also an "intermediary"; clearly it "is not the primary initiator or recipient of communications, but instead acts to facilitate communications".

Indeed, today in many applications the biggest and most common threats to the end user's privacy (think of surveillance advertising) come from what's happening within the "protocol endpoint", and that is what makes many of us feel that the model in 3552 is outdated. Making any considerations on the overall privacy and security of a protocol without looking at possible misbehaviour by intermediaries sitting at the protocol endpoint is a logical fallacy.

This is also why I would prefer to make recommendations on intermediaries only after having fully clarified the definitions above. There are cases in which intermediation is the only resort for a user to protect their privacy and security from misbehaving endpoints (e.g. a firewall or filter blocking IoT objects on the local network from connecting to undesired destinations, or preventing the unsuspecting user's browser to connect to a phishing page). We should first understand how the relationship between protocol intermediaries and endpoint intermediaries plays out in terms of user-centred objectives, and only then make recommendations.

--

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