Re: [Spud] Additional SPUD use-cases

[Richard Barnes <[e-mail]>]

I see.  That's a different question.  Seems like some sort of basic
consistency check / checksum would be sufficient?

On Thu, Mar 19, 2015 at 2:09 PM, Mirja Kühlewind <
[e-mail]> wrote:

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