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

Tero Kivinen <kivinen@iki.fi> Tue, 27 August 2019 13:01 UTC

Return-Path: <kivinen@iki.fi>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D0DF12012D; Tue, 27 Aug 2019 06:01:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.419
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQWOsPDpeXkM; Tue, 27 Aug 2019 06:01:12 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4CD612011B; Tue, 27 Aug 2019 06:01:10 -0700 (PDT)
Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (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 fireball.acr.fi (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: <23909.10610.552936.793775@fireball.acr.fi>
Date: Tue, 27 Aug 2019 16:00:34 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: "Pascal Thubert \(pthubert\)" <pthubert@cisco.com>
Cc: Roman Danyliw <rdd@cert.org>, The IESG <iesg@ietf.org>, Benjamin Kaduk <kaduk@mit.edu>, "shwetha.bhandari\@gmail.com" <shwetha.bhandari@gmail.com>, "6tisch\@ietf.org" <6tisch@ietf.org>, "6tisch-chairs\@ietf.org" <6tisch-chairs@ietf.org>, "draft-ietf-6tisch-architecture\@ietf.org" <draft-ietf-6tisch-architecture@ietf.org>
In-Reply-To: <MN2PR11MB35657EF40A759366396FD3FCD8A10@MN2PR11MB3565.namprd11.prod.outlook.com>
References: <156523837973.8301.2864865066450595993.idtracker@ietfa.amsl.com> <MN2PR11MB3565FC066DB6EB01DA5E30F1D8A50@MN2PR11MB3565.namprd11.prod.outlook.com> <359EC4B99E040048A7131E0F4E113AFC01B343BFC0@marathon> <MN2PR11MB35657EF40A759366396FD3FCD8A10@MN2PR11MB3565.namprd11.prod.outlook.com>
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: <https://mailarchive.ietf.org/arch/msg/6tisch/JnLPpDf0Ah7p4Oqq1GbYkn89Nvw>
Subject: Re: [6tisch] Roman Danyliw's No Objection on draft-ietf-6tisch-architecture-24: (with COMMENT)
X-BeenThere: 6tisch@ietf.org
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" <6tisch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:6tisch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6tisch/>
List-Post: <mailto:6tisch@ietf.org>
List-Help: <mailto:6tisch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:6tisch-request@ietf.org?subject=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. 
-- 
kivinen@iki.fi