With the default of 10 ms it takes 350 years to wrap ASN. That's long memory to keep for an attacker. Modern storage technology does not last that long.
But hey, 6TiSCH is designed to be easily portable to other deterministic MAC technologies (think RAW) which would be much faster. A reasonable time slot in 802.11 ax would be below 1ms, which would take is down to 35 years. But there are alternatives: - At some point we do not slot anymore, just provide precise time for transmission (think time-based shapers). - If we keep resource blocks of 10ms in 5G, there will be multiple packets, so ASN will need an extension (at least an additional octet that would be signaled in band) to count the packet with a finer granularity than ASN, within the time slot. I modified Archie based on Tero's comment to make it more abstract - just say nonce-reuse attack deferring to others on what the result of the attack can be - and indicate the 350 years. Please ssee if that's enough. All the best, Pascal > -----Original Message----- > From: Michael Richardson <[email protected]> > Sent: mardi 27 août 2019 19:44 > To: Tero Kivinen <[email protected]> > Cc: Pascal Thubert (pthubert) <[email protected]>; Roman Danyliw > <[email protected]>; [email protected]; [email protected]; The > IESG <[email protected]>; [email protected]; > [email protected]; > Benjamin Kaduk <[email protected]> > Subject: Re: [6tisch] Roman Danyliw's No Objection on draft-ietf-6tisch- > architecture-24: (with COMMENT) > > > Tero Kivinen <[email protected]> wrote: > > Pascal Thubert (pthubert) writes: > >> o The cryptographic mechanisms used by [IEEE802154] include the 2- > byte > >> short address in the calculation of the context. If the 2-byte short > >> address is reassigned to another node while the same network-wide > keys > >> are in operation, it is possible that this could result in disclosure > >> of the network-wide key due to reused of the > > > Even when the nonce reuse happens, I do not think there is any leak of > > the network-wide keys in that case. What is lost is the confidentiality > > of the those messages sharing nonce, i.e., only those messages are > > broken, not the whole network key. > > I had understood that it was worse. > The text has slightly changed since, but can you suggest better text? > So I've overstated the risk. > > >> o Many cipher algorithms have some suggested limits on how many > bytes > >> should be encrypted with that algorithm before a new key is used. > >> These numbers are typically in the many to hundreds of gigabytes of > >> data. On very fast backbone networks this becomes an important > >> concern. On LLNs with typical data rates in the kilobits/second, this > >> concern is significantly less. However, the LLN may be expected to > >> operate for decades at a time, and operators are advised to plan for > >> the need to rekey. > > > Note, that TSCH in general allows maximally of 2^40 frames to be sent > > before ASN rolls over. In normal case the maximum packet size is 2^7 > > octets, meaning the total amount of bytes that can be transferred over > > TSCH network is 2^47 octects, meaning 2^43 blocks of AES. Currently > > only cipher supported by the TSCH is AES-CCM-128 (altough 802.15.4y > > will be adding support for other algorithms too), but I think the > > maximum number of blocks recommened for one key for AES is more > than > > 2^43, so this should not be a problem at all. I.e., the ASN frame > > counter will be problem before this will be problem. Even if using the > > PHY with 2^11 max frame length that gives only 2^47 blocks at maximum. > > This analysis should be included, and I'll try to do that. > > I think that we MUST rekey before the ASN rolls over too? > Is that a major concern? > > I understood the ASN advances every 10ms in many networks, sometimes as > slow as 50ms. So let's call it 2^6/s? So the ASN rolls over after 544 years? > 2^(40-6) / (86400 * 365) = 544. > > I guess the point is that we don't have to rekey for cryptographic of ASN > roll- > over reasons. > > -- > Michael Richardson <[email protected]>, Sandelman Software Works > -= IPv6 IoT consulting =- > > _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
