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

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 27 August 2019 17:43 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 C1D5C1201C6; Tue, 27 Aug 2019 10:43:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZb1W3PFXmfF; Tue, 27 Aug 2019 10:43:36 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48B591200C7; Tue, 27 Aug 2019 10:43:35 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 3EACF3818D; Tue, 27 Aug 2019 13:42:27 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id E788C89; Tue, 27 Aug 2019 13:43:34 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Tero Kivinen <kivinen@iki.fi>
cc: "Pascal Thubert \(pthubert\)" <pthubert@cisco.com>, Roman Danyliw <rdd@cert.org>, "shwetha.bhandari\@gmail.com" <shwetha.bhandari@gmail.com>, "6tisch-chairs\@ietf.org" <6tisch-chairs@ietf.org>, The IESG <iesg@ietf.org>, "6tisch\@ietf.org" <6tisch@ietf.org>, "draft-ietf-6tisch-architecture\@ietf.org" <draft-ietf-6tisch-architecture@ietf.org>, Benjamin Kaduk <kaduk@mit.edu>
In-Reply-To: <23909.10610.552936.793775@fireball.acr.fi>
References: <156523837973.8301.2864865066450595993.idtracker@ietfa.amsl.com> <MN2PR11MB3565FC066DB6EB01DA5E30F1D8A50@MN2PR11MB3565.namprd11.prod.outlook.com> <359EC4B99E040048A7131E0F4E113AFC01B343BFC0@marathon> <MN2PR11MB35657EF40A759366396FD3FCD8A10@MN2PR11MB3565.namprd11.prod.outlook.com> <23909.10610.552936.793775@fireball.acr.fi>
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: <https://mailarchive.ietf.org/arch/msg/6tisch/mSWNPfL-f-hKBaml1WXrg6Z-3Hs>
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 17:43:40 -0000

Tero Kivinen <kivinen@iki.fi> 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 <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-