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

Michael Richardson <> Tue, 27 August 2019 17:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C1D5C1201C6; Tue, 27 Aug 2019 10:43:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NZb1W3PFXmfF; Tue, 27 Aug 2019 10:43:36 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 48B591200C7; Tue, 27 Aug 2019 10:43:35 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3EACF3818D; Tue, 27 Aug 2019 13:42:27 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id E788C89; Tue, 27 Aug 2019 13:43:34 -0400 (EDT)
From: Michael Richardson <>
To: Tero Kivinen <>
cc: "Pascal Thubert (pthubert)" <>, Roman Danyliw <>, "" <>, "" <>, The IESG <>, "" <>, "" <>, Benjamin Kaduk <>
In-Reply-To: <>
References: <> <> <359EC4B99E040048A7131E0F4E113AFC01B343BFC0@marathon> <> <>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Tue, 27 Aug 2019 13:43:34 -0400
Message-ID: <21458.1566927814@localhost>
Archived-At: <>
Subject: Re: [6tisch] Roman Danyliw's No Objection on draft-ietf-6tisch-architecture-24: (with COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 27 Aug 2019 17:43:40 -0000

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