See inline.

On Mon, Mar 26, 2018 at 9:00 AM Thomas Watteyne <>

> *About COSE_Key*
> The issue raised is that, during a rekey of key K2 by the JRC, the JRC
> cannot specify an ASN from which the new key is to be used.

The JRC would need to guess how long it may take for it to reach every node
in the network. I think that it makes sense that the JRC does not need to
be aware of network specifics. Instead, it can update the key of the 6LBR
last, signaling that it should start using it. Other nodes get the key
before, but don't use it until they see it in the network. Makes sense?

> A strong requirement is for a node NOT have a node rejoin for each rekey.

Agreed, this means we need to add the rekeying mechanism in the new version
of minimal-security.

> Must we use the COSE_Key structure?

The use of COSE_Key costs us 2 bytes of overhead, for the key type (kty)
parameter which is implicitly symmetric for us but we need to transport it
according to RFC8152.

All the other parameters are optional, and we can extend the COSE registry
with new parameters, if we need to.

We could also specify a 6TiSCH-specific key structure instead of COSE_Key,
going for arrays instead of maps and saving an initial estimate of 4 bytes *per

> Is the the message sent by the JRC containing the new key end-to-end
> ACK'ed, i.e. does the JRC know it got received?

The end-to-end ACK of the message carrying the new key can be issued with
all the mechanisms that we are discussing in the thread "Observe for

In the case of classical Observe, this would be a CON Observe notification,
followed by an empty ACK from the client.

In the case a joined node exposes a resource (e.g. /j) that the JRC POSTs
to, the ACK would be piggybacked with the 2.04 Created response.

> Thomas
6tisch mailing list

Reply via email to