Hello Pascal, Thanks a lot for your review, feedback and pointers to further applicability of this approach.
Best, /Marco On 4/4/19 4:59 PM, Pascal Thubert (pthubert) wrote: > I concur with Michael, this is interesting work. > > Note that > 1) It is possible to commute only a subset of the channel offsets at a given > time offset. This reduces the number of nodes that need to know about the > swap and thus the exposure to a leakage. > 2) security is not the only reason why swapping is useful. As you know, under > constant conditions, pairs of nodes will suffer from multipath fading on some > channels and not on others. Once this has been observed, it is possible to do > a selective swap to avoid the particular channels that affect a particular > pair of nodes. > 3) I have IPR on that sort of stuff (USPTO 9,673,856); it is not exactly the > method you propose but close enough. Just in case I'll ask to publish terms. > > All the best, > > Pascal > >> -----Original Message----- >> From: 6tisch <[email protected]> On Behalf Of Marco Tiloca >> Sent: jeudi 4 avril 2019 09:05 >> To: Michael Richardson <[email protected]>; [email protected] >> Cc: [email protected] >> Subject: Re: [6tisch] draft-tiloca-6tisch-robust-scheduling-01 --- rekeying >> permutation key >> >> 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 >> -- 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
