Re: [6tisch] Roman Danyliw's No Objection on draft-ietf-6tisch-architecture-24: (with COMMENT)

[Michael Richardson <[e-mail]>]

Tero Kivinen <[e-mail]> 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 <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-