Hi Michael, Thank you very much for your review!
We'll definitely take into account your comments for the next version. Please, find also some answers inline. Best, /Marco On 4/3/19 3:06 AM, Michael Richardson wrote: > I read draft-tiloca-6tisch-robust-scheduling-01. > > I found this to be an interesting way to both announce the schedule, and yet, > hide it. Very well done. <MT> Thanks! </MT> > > I have some initial comment about the section 3.1 about the adversary. > I wondered about why someone would do this. What's the benefit. > > It occured to me that an important point about the selective jamming is that > an attacker can mess with a competitors network while still permitting their > own network to operate! That might be worth adding. <MT> It's a very good point! We'll add this as an attack motivation in Section 3.1. </MT> > The document seems well written, although I'd like to have some example keys > and show how they permute things in practice so that implementors can > validate their work. <MT> Right, we will produce an example, possibly as an Appendix referred at the end of Section 4. </MT> > The additions to CoJP seems well done, I'm so glad we changed that to a hash > From an array :-) > > If the permutation is replaced whenever the network key is changed, > which means that the permutation is going to change! This means that some > nodes could be on the new permutation while others are on the old. > > A thought to deal with this is that the new permutation is not used until the > node switches to the new keys. EXCEPT that the adjacent nodes will now not > be listening at the right time, won't hear traffic encrypted with the new > key, and won't change over themselves. Authenticated enhanced beacons would > perhaps help here. Maybe I'm wrong about this problem. <MT> This seems to deserve some more text in the Security Considerations of Section 6.2, such as the following points. The new link keys and permutation keys are expected to be distributed together, just like for the described provisioning through the CoJP Join Response, possibly through the same procedure described in [1]. After a rekeying process is completed, a node should indeed start using the new permutation keys once switched to the new link keys only, i.e. after it has discarded the old key material as per the handling of the "link-layer key set" in [2]. If a node A discards the old key material (considerably) before a node B, they will be temporarily unaligned. That is, node B would temporarily secure outgoing messages still using the old key material [2] that A does not own anymore, and would still permute its schedule the old way. Eventually, B will also discard the old key material, e.g. after receiving and successfully security processing an incoming message secured with the new key material [2], of course though while still over its old-fashion-permuted schedule. Here enhanced beacons authenticated with the new key material seem to help. Also, a local upper bound can be enforced through a parameter similar to COJP_REKEYING_GUARD_TIME [2]. Then, the two nodes will be aligned again on both processing secure messages and permuting their schedule. What do you think? [1] https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-09#section-8.2 [2] https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-09#section-8.4 </MT> > -- > Michael Richardson <[email protected]>, Sandelman Software Works > -= IPv6 IoT consulting =- -- Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistagången 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se
signature.asc
Description: OpenPGP digital signature
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
