Mališa Vučinić wrote:
>> If we could delay the switch to the new schedule until *after*
>> COJP_REKEYING_GUARD_TIME has elapsed, then that might work.
>> Alternatively, if we could number the rekeys then a EB could signal
>> the switch to the new schedule some time after the keys
Dear all,
We have submitted the new version of the minimal-security draft fixing the
remaining issues that were brought during the 2nd WGLC and the Prague meeting.
In particular, this version:
- Resolves the JRC failure issue by relying on the mechanism specified in
OSCORE Appendix B.2
-
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 over the TSCH mode of IEEE 802.15.4e WG
of the IETF.
Title : Minimal Security Framework for 6TiSCH
Authors : Malisa Vucinic
> On 5 Apr 2019, at 20:15, Michael Richardson wrote:
>
> If we could delay the switch to the new schedule until *after*
> COJP_REKEYING_GUARD_TIME has elapsed, then that might work.
> Alternatively, if we could number the rekeys then a EB could signal the
> switch to the new schedule some time
On 5 Apr 2019, at 20:22, Michael Richardson wrote:
>
> Also so that the many unicast conversations needed to do the rekey can be
> spread
> across a large amount of time, letting the JRC reach out to even very sleepy
> nodes.
Good point indeed, sleepy nodes may miss the reception slots and
Mališa Vučinić wrote:
> As a reminder, in minimal-security we resorted to the current rekeying
> mechanism and not the one using the exact timestamp in the future when
> the whole network switches to new keys in order to avoid having to know
> the network notion of time at the
Mališa Vučinić wrote:
> My understanding is that the problem in the permuted schedule arises
> during COJP_REKEYING_GUARD_TIME after nodes in the network started
> using the new keys, but have still kept the old key in case someone has
It's not just during that time, but from the
The original intent was to allow the pledge to signal “I can act on this
parameter but not on that value that you gave me”, cherry-picking specific keys
from the key set or just copying the whole thing if nothing works. The previous
text optimized for that by mandating the value or its
*
* Call for Papers
*
*GoodTechs 2019
*
*5th EAI International Conference on
* Smart Objects and Technologies for Social Good
*
*
Hi Tengfei,
Thanks for these questions.
1. We're not protecting against selective jamming on the minimal cell
indeed. This is a tricky problem, because beacons must include enough
information for nodes to find out when to tx/rx for the join procedure, and
a not-joined-yet node can do it then so
Hello Mališa,
> Let me know what do you think.
thanks for the update, this addresses my concerns.
Only a small question remains: When a pledge sends [0 /* unsupported */,
42 /* some fancy extension */, X] as an Unsupported Configuration, why
should it send the full value that was sent with the
Hello Mališa, Michael,
Thanks for this discussion, I think this is a good summary of the problem.
Just to stress that the full-fledged approach, by making also
slotOffsets unpredictable rather than static (i.e. obviously
predictable) further greatly decreases the attack surface, since a
Hello Tengfei,
Thank you for your review!
As to your comment on Equation 1, we used 'c' to highlight it as the
unknown variable when solving the equation, but indeed it refers to the
channel offset. We will make this explicit in the text.
Best,
/Marco
On 4/4/19 8:57 PM, Simon Duquennoy wrote:
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
14 matches
Mail list logo
