Re: [Spud] SPUD Scope?

[Szilveszter Nadas <[e-mail]>]

Hi,

My concern is whether the whole SPUD exercise is worth the effort without extensibility. Assume that we can agree in a minimal set for b). What if in a few years' time we realize that we need more? Have not we already ossified the middlebox layer? My vision is that SPUD shall allow both Transport Protocol evolution and Middlebox Cooperation evolution in the same flexible way. :) The goal in my mind if to not ossify transport and not ossify the cooperation functionality. 

Also is not b) + extensibility = c)? Or is there more in c), which is of concern?

About "metadata that our protocols leak", I completely agree that protocols should minimize this leaking. I think that explicit conversation is not leaking though and hopefully also discourages the middlebox owners to try to look into the protocol data itself.

Any device/firmware/Operating System/app still have and will have ways to leak whatever it wants, just by not allowing extensibility in SPUD we cannot stop it. At the same time extensible SPUD can be an engine for "good" cooperation. I believe we can potentially gain more than we lose. The only way to stop leaking is to have a "purging proxy", but even that proxy would have pretty hard time to remove all unwanted interactions. Also there are places where you simply cannot place a purging proxy e.g. between your access device and the ISP/mobile operator middlebox.

About "keeping the smarts at the edge" the IAB program at least includes a goal to "(2) Improving path transparency in the presence of firewalls and middleboxes: guidelines for the detection of and cooperation with these devices to evolve away from present limitations on which protocols can be used across network boundaries, in order to facilitate innovation in transport protocol development. ". In a sense it means for me to embrace middlebox functionality, but make it much more explicit. I think that these functions are important to keep our networks working, but I agree that it has to be much more explicit than in the past. But limiting it looks like a way to keep it in the grey.

I agree that security of the metadata layer will be often equally important than the security of user content. I am not quite sure whether it could/should be handled in SPUD or whether SPUD shall "only" allow secure metadata conversions as a substrate. 

About the UI/UX concern. This is definitely an issue and not an easy one to solve. Trust chains, delegation of trust, market apps controlling app rights are pieces of the puzzle to solve this. I think it is possible to find a solution for this with a good balance of ease of use and control. 

Sz.

-----Original Message-----
From: Christian Huitema [mailto:[e-mail]] 
Sent: Thursday, June 04, 2015 21:34
To: Daniel Kahn Gillmor; Szilveszter Nadas; [e-mail]
Subject: RE: [Spud] SPUD Scope?

On  Thursday, June 4, 2015 12:25 PM, Daniel Kahn Gillmor wrote:
> To: Szilveszter Nadas; [e-mail]
> Subject: Re: [Spud] SPUD Scope?
> 
> On Thu 2015-06-04 12:28:34 -0400, Szilveszter Nadas wrote:
> 
> > The rage looked like this to me on a high level:
> >
> > a) only start/stop, hide everything in DTLS
> >
> > b) Some declarative, safe to ignore, trust but verify markings are 
> > OK, but it shall be minimized.
> >
> > c) "common, middlebox friendly connection/packet signaling layer", 
> > extensibility, any communication and behavior is OK as long as it is 
> > explicit.
> 
> [...]
>
> This far-from-trivial authentication mechanism, combined with the 
> UI/UX concern about helping people to understand exactly who they are 
> leaking their metadata to, presents a really serious obstacle to 
> deploying something like this in a way that is safe for end users.

Absolutely. This might only work if the client, server, and middleboxes incentives are well aligned. That may be the case for some basic QOS-type parameters, which is very much what (b) should be about. 

> ...
>
> I don't think something like (c) is a good idea.  let's try to keep 
> the smarts (and the knowledge of both content and metadata) at the 
> edges of the network, and avoid blessing mechanisms that facilitate centralized surveillance.

And a variety of security issues. The unauthenticated data channel is subject to spoofing, which enables a variety of packet injection attacks. 

-- Christian Huitema