Re: [Spud] Possible WG-forming follow-on to SPUD BoF

[Szilveszter Nadas <[e-mail]>]

Hi Brian,

Thanks. Some further comments inside.

Cheers,
Sz.

> > -"allow applications and transport protocols to explicitly provide limited
> information in cleartext to devices on path" vs. "sending endpoint", "receiving
> endpoints". The terminology is not 100% clear to me. What is the difference
> between "applications and transport protocols" and "endpoints" here?
> 
> Some information to be exposed (e.g. expected constant data rate) might
> come from the application layer, and some information (e.g. transport
> reordering tolerance, measurement headers that look something like those in
> the PDM DO header the IPPM WG is currently working on) comes from the
> transport layer. In this case, the transport should always allow the application
> to know what is being sent, and to have control over whether it is sent, but
> may keep the application from changing the values exposed. This is up to the
> transport/app API.

I see. And now I can ask my real question: is it intentional to limit declarations to "applications" and "transport protocols" in the "endpoint"? What about other entities like a middleware? Or an OS level function which acts on behalf of the user's interest vs. the applications being maybe too selfish? 

(I refer to Fig. 1. of https://www.iab.org/wp-content/IAB-uploads/2015/08/MaRNEW_1_paper_16.pdf  )

> > -What do we gain by limited vocabulary ("limited information")? Is not any
> set of declarations too much for some users/countries/whatever and too few
> for others? Is not it forcing the WG participant's ethics by protocol design?
> 
> A few things; mostly, we gain some control at the process level against
> subversion of endpoint control.

Please elaborate it more. I do not get it.

> > -There was a comment "PLUS header would make this behavior visible to
> *everyone* on the network. That alone is IMO a reason it wouldn't be
> deployed in this way". I agree with this, PLUS would/shall make every non-e2e
> conversation as explicit as possible. Is that protection enough? Is it possible to
> make this explicitness as transparent as possible? Is it necessary to have further
> protection as e.g. limited vocabulary?
> 
> WRT "limited vocabulary", the thing it's hard to defend against here is
> someone defining their own declaration, the meaning of which is secret and
> the name obfuscated. If I see that an app is radiating something to the path
> over PLUS, but I can't understand it, well, I do know that app may be up to no
> good, but I don't know what *kind* of no good. It's not clear to me whether
> that's enough to qualify as "transparent".

Another way to implement it in the long run is to delegate the task of declarations to a trusted piece of software (again like in the marnew paper). Then this trusted piece could decide whether to send any data, and to encrypt it also.

Of course it is hard to prevent steganography in both cases.

> I'll note that if there was a "app-to-path-cleartext-supercookie" information
> element in PLUS (which I don't think would be a useful one to have, nor would
> it meet any goal we have), it would *not* be removable by a middlebox, since
> it would be integrity protected end-to-end. A supercookie mitigation box in
> PLUS would have to notice the existence of the supercookie, drop the packet,
> and send back a direct feedback message that said "I'm sorry, I don't permit
> supercookies, please reset the superstrate transport session and try again
> without the supercookie."

This makes inserting any middlebox declaration to the packet impossible. That was discussed before, is it not in scope anymore? 

> > -The charter still says "goal is to enable the deployment of new, encrypted
> transport protocols". I think that whether to encrypt or not is the decision of
> the TP, and while I agree that encryption really helps there by avoiding further
> ossification, I think it shall not be the scope/decision of PLUS.
> 
> Yes, but: in order for integrity protection of declared information to work,
> PLUS needs a mechanism to share a secret between endpoints, so it either
> needs its own keying or it needs to borrow a key generated from the
> superstrate's session key. And if we are to meet the requirement to prevent
> future ossification of the transport layer (or rather, to re-ossify around the
> path layer provided by PLUS), then we need to encrypt the transport layer
> headers. So IMO this is very much in scope.

This definitely makes sense. I am not sure whether this is the best compromise though. 

The requirement is to be able to provide some kind of integrity protection and encryption capabilities in PLUS, in a lightweight way. Reusing TP security context is definitely a solution, there might be issues with that, not sure.