See inline. On Mon, Mar 26, 2018 at 9:00 AM Thomas Watteyne <thomas.watte...@inria.fr> wrote:
> > *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 key*. > 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 rekeying". 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 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
