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

[Martin Thomson <[e-mail]>]

Hi Jari,

On Fri, Jul 31, 2020, at 02:01, Jari Arkko wrote:
> First off, the draft uses some examples from low-in-the-stack 
> intermediaries, many of which aren’t as relevant today as they were 
> earlier. It would be interesting to consider email services (that don’t 
> support good e2e keying, and at the same time benefit from the analysis 
> of the emails for commercial surveillance), DNS resolvers, and other 
> similar cases with more current relevance.

Yes, email is a great example.  I should find some way to lean on that for material.  There are good reasons for its current architecture, but I tend to think that these would not be good choices for a modern system.

Other than acknowledging their existence, I did specifically try to avoid making strong statements about the other topics that are "live".  Thus, the suggestion to talk about DNS resolvers is something we should keep exploring in ADD contributions (I tend to think that is a poor source of exemplary material here, but you might disagree).
 
> I think Section 2 and the definition of intermediation needs work. 
> Where do we draw the line between functions pass communications from A 
> to B, vs. functions that are used in some form in the communications 
> between A and B? Lets say a translation or discovery service. In either 
> case function may learn things that are private to the communicating 
> parties, it may impact the ability of the communicating parties extend 
> whatever they are doing with new functionality, and so on. Are these 
> intermediaries in the sense of the draft, or not? And why?

Do I consider recommendation engines - the like of which are used by Facebook, Youtube, Twitter, and other social media - intermediaries?  Maybe.  I explicitly identified social networks as intermediaries, but they are not a singular thing, and their role is not always intermediary in nature.

Discovery services - in the general sense - occupy an interesting point in this space.  They have the ability to inject themselves in the eventual communication (DNS and LoST are examples at a lower layer where injection rarely occurs; SIP operates at a higher layer and tends to end up with lots of intermediation).  For DNS, we would regard a resolver as an intermediary of the worst unwanted kind if it decided to provide its own address in place of the real answer and subsequently attempted to intermediate the application protocol. (This is entirely possible for email, incidentally.)

Translation services are more directly intermediaries.  But I'm not sure what you mean exactly there.  Protocol translation is often accomplished by intermediaries anyway.  It's rare to have protocol translation as a pure service, though it could in theory operate differently.  (Human language translation services are different: it offers a way to intermediate that doesn't involve intermediation in any real sense, it's only when you move to real-time interpretation that you introduce an intermediary.)

> Thirdly, I think there’s an issue in the following:
> 
>    Many problems caused by intermediation are the result of
>    intermediaries that are introduced without the involvement of
>    protocol endpoints.
> 
> This conflates the role of protocol endpoint and the role of users, 
> equipment owners, etc. A lot of today’s problems are caused by issues 
> where some piece of service or software or equipment does something 
> that isn’t aligned with my interests as the user. 

Here you have hit on a point I knew you would find troubling.  As I said when I introduced this, I don't see this as addressing the entire problem space here.  The idea is that we might run software that is written with goals that are not entirely congruent with our own, or use services that are motivated to exploit the access they gain for their own ends.  In most of these cases we have very little real choice even, which further enables bad behaviour.

But as the basis for protocol design, at least within the scope of this document, I don't see that as a useful problem to have identified.  This is a document aimed at protocol designers, so it necessarily assumes that actors in the system act rationally and in their own interests as it pertains to the protocol.  While the study of Byzantine systems is a great academic exercise and useful in systems design, we don't get very far when designing protocols that way.  So, like RFC 3552, this assumes that each endpoint represents its own interests.  Those might be nefarious in many ways, but as far as the protocol is concerned, it is reasonable to expect conformance to the contract of the protocol.

That doesn't make this an invalid angle to consider in general.  The question of designing for eventual endpoint compromise in a managed network, or subsystem compromise on a complex host, is a completely different angle.  The question of how we deal with differently aligned incentives of the systems, subsystems, components, and whatnot that we depend on is something else again.  I don't have a good view of where this program is going yet.  I think that we need all of the above, of course, but that seems unmanageable.