Re: [6tisch] Observe for rekeying (was: Updates to minimal-security-06)

[Mališa Vučinić <[e-mail]>]

Hi Christan,

Thanks for your response and apologies for the slow follow up. See inline.

Mališa

On Mon, Mar 26, 2018 at 10:42 AM Christian M. Amsüss <[e-mail]>
wrote:

> Hello Mališa,
>
> On Fri, Mar 23, 2018 at 10:12:16AM +0000, Mališa Vučinić wrote:
> > I am tempted to say that this does not prevent us from updating the
> client
> > endpoint (but not the token) based on implicit knowledge at JRC. Do you
> > agree?
>
> observation is fundamentally a hop-to-hop thing (terminated at proxies);
> both the token and the observation counter are scoped to those hops, and
> while a minimal proxy may get away with passing them on unmodified, I
> doubt that that can be used to form a stable mechanism.
>
> The topic of a delegated observe has been brought up before[1] (with a
> focus on nomadic devices), and was not followed up to after initial
> comments. If minimal-security were to do observations that hops off a
> proxy observation to a direct one, it'd need a specification similar to
> that (with its holes filled) to let that observation hop off smoothly.
>
> (Whether the observation is FETCH or GET is immaterial here, and in this
> setting it's a good approximation to say that the difference is that the
> FETCH allows binary data with a mime type to be part of the request,
> which would in a GET need to be squished into a query string).
>
>
> As I understand, even richardson-6tisch-minimal-rekey needs to transport
> that modelled data, so at any rate I can suggest two alternatives to a
> hopping observation:
>
> * Don't observe through the proxy, but establish an observation after
>   the address has been assigned.


>   This incurs cost of two additional packages, but is conceptually
>   simple and straightforward.
>

Yep, so two messages to join and two additional messages for the first
rekey to happen.



>
> * Establish a dynlink (formerly bindings) to make the JRC PUT (or PATCH)
>   the node.


>   This would take two additional messages as well (the former pledge
>   requesting a dynlink once it knows its final address, plus its
>   response). This is the less common but more versatile approach to
>   observation.


>   An advantage over plain observation is that it might be possible to
>   establish this link in another way than explicitly requesting it (eg.
>   piggy-backing an "and when you've managed, please keep me posted on /X
>   relative to whatever address I might have then", or by the JRC knowing
>   from somewhere else that such a binding is to be established)
>

What would be the advantage of establishing a dynlink over specifying in
the minimal-security draft that once the pledge joins, it needs to expose a
/j resource that the JRC may use to update the keying material? This would
essentially be a static link specified in the draft. Do you see any pitfall
with that?


6tisch-minimal-rekey sounds like it is a valid expectation that the
> nodes will use CoMI; if that is the case and this approach is followed,
> the PUT/PATCHing that would be the result of a dynlink cold probably be
> set up implicitly.
>

I don't think we have the consensus on the use of CoMI in minimal-security.
We considered it for future work, but at this point I would refrain from
pulling in new specifications..


>
> Best regards
> Christian
>
> [1]:
> https://mailarchive.ietf.org/arch/msg/core/-emsRTJmyyFHlrNwbJkqGfXQaYw
>
> --
> To use raw power is to make yourself infinitely vulnerable to greater
> powers.
>   -- Bene Gesserit axiom
>