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

From: Jari Arkko <[email-masked]>
Date: Tue, 7 Dec 2021 01:34:14 +0200

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

Summary

This document (https://datatracker.ietf.org/doc/html/draft-thomson-tmi-02 <https://datatracker.ietf.org/doc/html/draft-thomson-tmi-02>) discusses the roles of endpoints vs. intermediaries, using a pretty broad definition of intermediaries, which could be anything from a cache to a DNS service to even just a router. The document argues that the intermediaries are a necessary and useful part of the Internet. Indeed, if there were no functions whatsoever in the network, there’d be no network at all. But there are tensions when the interests of the endpoints are not aligned with the interests of the intermediaries, and when for instance an intermediary does more than the endpoints wish it to do. The document proposes three principles around ensuring proper use of intermediaries, on avoiding intermediation, limiting who can be an intermediary, and limiting what the intermediaries are allowed to do.

Relevance

The document addresses a topic where there is often some tension between different interests and systems, as evidenced by various discussions on network functions interacting with end-to-end encryption, the role of various helper functions and how much information one wants to give them (DNS, various relays), or the discussions on application - network path signalling and information exchanges.

It is perhaps not the only* topic of interest to model-t type discussions, but it is interesting and relevant. 

*) Specifically, I think model-t should also think about the you-may-not-entirely-trust-your-endpoint issue, because that is a new and increasingly pressing issue. Of course that is not the only thing to focus on either.

Contribution

The overall question of tensions between endpoints and other parts of the system has of course been a long-standing topic. This document does not go beyond that particular topic, but focuses on a particular class endpoint vs. others, namely on how to interact with services that are not part of the endpoints but which are still beneficial for some purpose (forwarding, name resolution, etc.) It proposes a useful framework of three principles to guide future designs.

Detailed comments

Principles — in general, these seem spot on, and adequately described.

Definition of an intermediary (Section 2) — I think this is a simple definition, but I found the DNS example confusing. The draft talks about how DNS in general is not an intermediary, because it doesn’t actually intermediate communication. But yet the definition actually said “facilitate communications” which could include things like name resolution? Yet the draft says that recursive resolvers are intermediaries. Maybe I’m missing something, or perhaps some sharpening of the definitions is needed. Intuitively, my ISP’s or Google recursive resolver sits process-wise between me and my communications to a destination; and I’d like to limit what info I give them. So it feels like an intermediary, as the draft does say as well. But what’s the distinction then to, say, a root server, or the authoritative DNS server for the domain?

Intermediation is essential (Section 3) — good! Good examples.

Intermediation is useful (Section 4) — also good. Perhaps this section could also talk about the different ends of the scale. As the section says, individuals do not have scaling benefits than e.g. an ISP or CDN operator has, which has benefits for attack defence. But on the other end of the scale, resilience suffers if we attempt to aggregate everything to a single intermediary service. Aggreagion is useful to a point.

Intermediary enables scaling of control (Section 5) — agreed. Of course there’s similar arguments about endpoints, such as your favourite service or software. But that is perhaps a topic for some other work in the model-t space.

Incentive misalignment (Section 6) — yes.

Forced and unwanted (Section 7) — Agreed. But here it might be useful to discuss also a bit more about the types of forcing that are possible. There seems to be two eras, one where due to lack of encryption various kinds of “I’m on the path” devices were able to become intermediaries. What’s left when we move to the all-encrypted world? Would you consider intermediary services chosen by an app as forced? What about software limitations on your device that force you to the kind of intermediation that you’d rather not have (e.g., sending cleartext email through a server) but have no choice to avoid? Also, perhaps as a general point it might be useful to discuss more examples from the application level intermediaries in the document. I think you’d have plenty of messaging and email examples to use, Martin.

Contention (Section 8) — I wonder if there was a more clear conclusion from the SRv6 example — I do agree that some network tricks really are about tunnelling, in some cases using a particular way to encode the tunnel bits. But is tunnelling in general intermediation? Or harmful? Or only if it modifies (even temporarily) the packet? 

Services over intermediation (Section 9.1) — this leads me to back to the definition. Is an intermediary only an intermediary if the all communications flow through it? What if some information flows to it, but not all? Is it an intermediary if it can make a decision about something, like whether I can connect to example.com <http://example.com/>? Perhaps a different way to phrase the Section 9.1 principle is to focus on the information and modularity, not whether we call a thing service or intermediary. If I have a need for a function, I’d like that function to learn the minimal amount of information from what else I’m doing. I ask someone to perform that function, I get an answer, and then I go on my business to continue whatever else I may need to do. Not that I handle everything via that something which both sees my traffic while performing whatever small function I needed.

Your discussion of avoiding the intermediaries to become participants is spot on. This is also a benefit of the service model (or the limited-data-limited-function model): when I contact a service to perform a simple task, the rest of my communication partners don’t have to know about that and don’t have to prepare for N-way negotiation or error cases.

Deliberate selection (Section 9.2) — nice extension of the 8558 principle!

Limit capabilities (Section 9.3) — Good. There seems to be also some relationship to the Section 9.1 principle in terms of limiting the function/service to the minimal, modular function.

Conclusion

Thanks for interesting and useful work! I think this should somehow proceed towards an IAB RFC, although perhaps some further discussions/changes might be useful.

Jari

---

From: Vittorio Bertola <[email-masked]>
Date: Wed, 8 Dec 2021 08:14:04 +0100 (CET)

> Il 07/12/2021 00:34 Jari Arkko <[email-masked]> ha scritto:
> 
> 
> Hi,
> 
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
[email-masked] mailto:[email-masked]
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: Watson Ladd <[email-masked]>
Date: Wed, 8 Dec 2021 08:05:04 -0500

> 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 u…

I don't understand how the Internet Engineering Task Force can
meaningfully address endpoint security. Nor have I seen an example of
how 3552 updates would meaningfully address this, or changes in
protocols that would help either. If the product you want is Ware
report 2.0, that's potentially valuable, but not I think what we need
for the I part of the IETF.

-- 
Astra mortemque praestare gradatim

---

From: Vittorio Bertola <[email-masked]>
Date: Wed, 8 Dec 2021 14:20:31 +0100 (CET)

> Il 08/12/2021 14:05 Watson Ladd <[email-masked]> ha scritto:
> 

No, device security is out of scope, but the choice of protocol architectures is directly influenced by whether you want to consider potential "endpoint intermediary" misbehaviour or not, which in turn will influence your take on whether hooks for other intermediaries in the conversation (in the network, as side services, however you want) are desirable or not. Yesterday someone was pointing out the work that the W3C is doing ( https://github.com/w3ctag/privacy-principles ), I still need to go through it but at first sight it looks like an interesting approach.

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

---

From: Jari Arkko <[email-masked]>
Date: Wed, 8 Dec 2021 16:21:53 +0200

I don’t think we or should address endpoint security, but rather the interaction between communications and how much we can trust endpoints for various reasons*. 

Martin’s draft for instance argues we should not give intermediaries extra tasks or information or control opportunities, except in very well justified and limited situations. My draft argues that for instance a client should not divulge information to a server, unless it has a well-justified reason for having that information, and controls in place to limit what information it gets or how it uses it.

Jari

*) That we don’t have 100% trust can be for many reasons, either due to potential attacks, lack of protection in the endpoints, or merely differing interests. Often all three :-)

---

From: Mohit Sethi M <[email-masked]>
Date: Wed, 8 Dec 2021 14:58:25 +0000

Initially, I had a similar opinion: if an endpoint is compromised -> 
game over. You can't do anything about communication security.

But I changed my opinion after reading, understanding, and evaluating 
misbinding attacks: https://dl.acm.org/doi/abs/10.1145/3321705.3329813 
(sorry for self-publicity). Essentially: an honest endpoint can prevent 
a compromised endpoint from involving another honest endpoint into the 
conversation to play confusing games on who is talking to whom. 
Protocols can build mitigations to prevent such games if an endpoint in 
a conversation is compromised.

The same applies to Jari and Matrin's draft. If you tell less about 
yourself to the other endpoint, there is less information available to 
the attacker when the endpoint is eventually compromised.

I think the goal of model-t is not to improve endpoint security. Its 
what bad things can a communication protocol prevent when an endpoint is 
compromised?

--Mohit

---

From: Watson Ladd <[email-masked]>
Date: Wed, 8 Dec 2021 13:14:48 -0500

> No, device security is out of scope, but the choice of protocol architectures is directly influenced by whether you want to consider potential "endpoint intermediary" misbehaviour or not, which in…

What's the difference between a coffeeshop, an ISP, and a corporate
network to an end device? If we make a protocol to prevent people
sending viruses over email, will it then stop them sending pictures of
Winnie the Pooh? Bytes are bytes after all.

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 09 Dec 2021 16:31:20 +1100

On Wed, Dec 8, 2021, at 18:14, Vittorio Bertola wrote:
> Then, abruptly, recommendations start and they are all about avoiding intermediation at all costs. 

I can't see that as anything other than a straight up mischaracterization.

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

This definition is, I think, not really the right one.  I've been struggling with this for some time, but didn't have a good handle on it.  Jari's email sharpened that point somewhat.  

I think that the definition I'm really looking for is for an entity that handles the content of communications that are exchanged between the primary beneficiaries of those communications.  "Handles" being that they are responsible for receiving and forwarding that content, even if they can't always see or modify all of it (thanks to encryption).

Distinguishing this from the broader category of facilitators is important.  I was hoping the DNS example would help sharpen that, but clearly it made things worse.  If you do your own recursion, then DNS is a bunch of services.  But people tend to use shared recursive resolvers because those come with performance and (maybe) privacy advantages.  It's a useful illustration of the trade-offs involved.

More work on the definition is needed, but that is where I was headed with it.

To take a less-often used example, in WebRTC there are signaling servers, who intermediate the signaling stuff (control plane if you will), but do not intermediate the media (data plane).  Media is intermediated in different ways by selective forwarding units (SFUs) or bridges or mixers or focuses (there are lots of names for these and lots of ways to build them). There are also relays, which are intermediaries that help with NAT and sometimes firewall traversal.

All of these are intermediaries in that they receive packets and forward them in different ways, but the extent to which they are exposed to communication content varies greatly.  Relays only see an encrypted envelope.  SFUs might see all of the media, but they might see a lot less if we ever get SFrame deployed as a standard (some services are already deploying it).  Old-style SFUs are bad according to these principles because they have more access than they need; newer ones have the access they need (following the RFC 8558 advice) and so are better.

We've established unequivocally that real-time communications can't really do without intermediation in these cases. The choice to use an SFU is generally carefully considered, not an accident. Mostly because they are very complex and expensive to operate.

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 09 Dec 2021 16:44:03 +1100

On Thu, Dec 9, 2021, at 01:21, Jari Arkko wrote:
> *) That we don’t have 100% trust can be for many reasons, either due to 
> potential attacks, lack of protection in the endpoints, or merely 
> differing interests. Often all three :-)

This "do you trust me?" view is something I think we're all agreeing about.  That is, trust is not Boolean, it should be contextual, purposeful, and limited in scope.  When it comes to protocol design, this is generally all we can say.

To some extent, I despair that we have to write down something like the data minimization principle.  But Mozilla had to [1] and we're considered a pioneer in that regard.  From a security perspective, it's an application of the principle of least privilege that I see being routinely ignored.  We should not judge the inclusion of new data on the basis that it might be useful. We should maintain a higher standard.  

QUIC was, I think, an example of that.  In the extreme, the spin bit is perhaps the most well-justified bit in any protocol (RFC 3514 being a possible exception), but that general design ethos was applied throughout and that had benefits in terms of efficiency and simplicity[2] as well as security.

Jari's draft goes further than I think is necessary - something I'll send a separate mail on - but I do think that a document on minimization could be a valuable contribution to the literature.

[1] https://www.mozilla.org/en-US/about/policy/lean-data/
[2] Yeah, it's hard to say that QUIC is simple, but it could have been MUCH worse.

---

From: Vittorio Bertola <[email-masked]>
Date: Thu, 9 Dec 2021 19:08:24 +0100 (CET)

> Il 09/12/2021 06:31 Martin Thomson <[email-masked]> ha scritto:
>  

That was really not my intention, but the above is indeed how the document sounded to me.

> This definition is, I think, not really the right one.  I've been struggling with this for some time, but didn't have a good handle on it. 

I think that we need to do more work on mapping, conceptualizing and classifying all parties that take part in an online exchange of data "human-to-human", with "human-to-server" being an alternative case too. Once we have that clear, it could become easier to discuss the threats that each class of intermediaries may pose, and understand what could be done about it in terms of protocol design.

Also, I agree with what you were saying elsewhere, that in the end you need to let users trust some of these intermediaries, as users will naturally do so. My basic point is just that there are use cases in which people trust the network more than the protocol endpoints.