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

["Pascal Thubert (pthubert)" <[e-mail]>]

All the best,

Pascal

> -----Original Message-----
> From: Tero Kivinen <[e-mail]>
> Sent: mardi 27 août 2019 15:01
> To: Pascal Thubert (pthubert) <[e-mail]>
> Cc: Roman Danyliw <[e-mail]>; The IESG <[e-mail]>; Benjamin
> Kaduk <[e-mail]>; [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Subject: Re: [6tisch] Roman Danyliw's No Objection on draft-ietf-6tisch-
> architecture-24: (with COMMENT)
> 
> 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'd really like to understand that. This is too deep for Archie anyway. I'll change the text to indicate that a nonce-reuse attack would be possible.
Does the below work?

" 
      The cryptographic mechanisms used by IEEE Std. 802.15.4 include the 2-byte
      short address in the calculation of the context.
      A nonce-reuse attack may become feasible if a short address is reassigned
      to another node while the  same network-wide keys are in operation.
"


> 
> >    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.

Many thanks, Tero, all this is really useful. What about:

" 
      With TSCH as it stands at the time of this writing, the ASN will wrap
      after 2^40 timeslot durations, which means with the default values around
      350 years. Wrapping ASN is not expected to happen within the lifetime of
      most LLNs. Yet, should the ASN wrap, the network must be rekeyed to avoid
      a nonce-reuse attack.

      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. With IEEE Std. 802.15.4 as it stands
      at the time of this writing, the ASN will wrap before the limits of the
      current L2 crypto (AES-CCM-128) are reached, so the problem should never
      occur.

      In any fashion, if the LLN is expected to operate continuously for decades
      then the operators are advised to plan for the need to rekey.
"

All the best;

Pascal