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

Tero Kivinen <> Tue, 27 August 2019 13:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4D0DF12012D; Tue, 27 Aug 2019 06:01:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.419
X-Spam-Status: No, score=-3.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qQWOsPDpeXkM; Tue, 27 Aug 2019 06:01:12 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B4CD612011B; Tue, 27 Aug 2019 06:01:10 -0700 (PDT)
Received: from (localhost []) by (8.15.2/8.15.2) with ESMTPS id x7RD0caG015268 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 27 Aug 2019 16:00:38 +0300 (EEST)
Received: (from kivinen@localhost) by (8.15.2/8.14.8/Submit) id x7RD0YIu019788; Tue, 27 Aug 2019 16:00:34 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <>
Date: Tue, 27 Aug 2019 16:00:34 +0300
From: Tero Kivinen <>
To: "Pascal Thubert (pthubert)" <>
Cc: Roman Danyliw <>, The IESG <>, Benjamin Kaduk <>, "" <>, "" <>, "" <>, "" <>
In-Reply-To: <>
References: <> <> <359EC4B99E040048A7131E0F4E113AFC01B343BFC0@marathon> <>
X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd)
X-Edit-Time: 10 min
X-Total-Time: 22 min
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 13:01:15 -0000

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.

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