Re: [Spud] Additional SPUD use-cases

[Mirja Kühlewind <[e-mail]>]

Okay, the question is than rather, how can we avoid that non-spud-aware middleboxes accidentally modify spud information which can hinder spud deployment is the same way other approaches failed…? I think we should at least be somehow able to detect these kind of unintentional modifications.

Mirja


> Am 19.03.2015 um 13:56 schrieb Richard Barnes <[e-mail]>sx>:
> 
> Honestly, this seems quixotic.  Can we just specify that SPUD has a stack of messages, and leave it at that?
> 
> Since there's no authentication of the middleboxes, the endpoint can't tell the difference between a middlebox changing a value and just deleting it and replacing it, which it can still do in this scheme.  
> 
> You might think you could prevent middleboxes from seeing each others' messages, but since there's no authentication on the *endpoint* keys, a middlebox could just replace the key and send the messages on, then take things on the return path, snarf whatever messages it wants, and re-encrypt them to the real key.
> 
> So there is very limited benefit here, if at all.
> 
> On Thu, Mar 19, 2015 at 1:17 PM, Joe Hildebrand (jhildebr) <[e-mail]> wrote:
> On 3/19/15, 9:38 AM, "Mirja Kühlewind" <[e-mail]> wrote:
> 
> >just a quick though on our comment regarding basically ‚why does DSCP not work inter-domain‘. One answer to this question is that is it mostly used intra-domain and that’s okay. That’s why we look at SPUD because we actually what something inter-domain (at least to signal information without negotiation). Therefore the questions for SPUD are for me:
> >
> >- How can we ensure that information provided by the end-point does not get modified?
> >
> >and more complicated
> >
> >- How can we ensure that information a middlebox puts in is not (wrongly) modified by another middlebox (as there are cases, we we want one middlebox to override data of another middlebox…?)
> 
> I'm CC'ing in some people that I know are interested in working on "COSE", a recoding of JOSE into CBOR, but who may not be subscribed to the SPUD list.
> 
> One approach we could take is have the client put a (tube-specific? time-limited?) public key into each OPEN packet in a path-accessible way.  Assertions from the application could be signed with the corresponding private key, assertions from the path could be encrypted with the public key.
> 
> I'm worried about the CPU overhead for middleboxen, but we could both make this optional in the protocol and required-by-default in the library to see what the market shakes out as use cases.
> 
> --
> Joe Hildebrand
> 
> 
> 
>