Re: [Spud] Additional SPUD use-cases

[Richard Barnes <[e-mail]>]

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