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

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Tue, 27 August 2019 14:48 UTC

Return-Path: <pthubert@cisco.com>
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 83257120826; Tue, 27 Aug 2019 07:48:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=V9zmzed2; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=ejDgvken
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 KOnG6hLf51Kc; Tue, 27 Aug 2019 07:48:10 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24CCD120827; Tue, 27 Aug 2019 07:48:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4280; q=dns/txt; s=iport; t=1566917289; x=1568126889; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=/U4snU7L2cTCnv/ElILzIcQTd2A5tUKiDaZcgmoV7M8=; b=V9zmzed2S3ZSv//1TJ/ZHkfMJCzV78UeqXoW7N+Rj0cvpZfTAP/O9w4F JnnNaWyQTXPxTR4PZLGK4rYEJzM+BcIj8ul5wWreQKvIqvWbMp7iMTJfo XYBkBebgtVoCbm3y243oFtodDgvlXdRWLHpVN3eHG3F2hmMUS8koxNK+C o=;
IronPort-PHdr: =?us-ascii?q?9a23=3Ay858CBxMiBC+WMPXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5YhWN/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1?= =?us-ascii?q?kAgMQSkRYnBZudFU3mJvPwcwQxHd9JUxlu+HToeUU=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BDBgDMQWVd/5tdJa1lHAEBAQQBAQc?= =?us-ascii?q?EAQGBZ4FFUAOBQyAECyqHaAOKck2CD4lgjgmCUgNUCQEBAQwBAS0CAQGEPwK?= =?us-ascii?q?CRiM4EwIKAQEEAQEBAgEGBG2FLgyFSgEBAQMBEi4BATcBCwQCAQgRAQMBAS8?= =?us-ascii?q?hERcGCAIECgQFCBqEawMODwECn3ICgTiIYYIlgnsBAQWFBQ0LghYJgTSJLIE?= =?us-ascii?q?GgSYdGIFAP4ERRoJMPoIagiyDO4ImjCGCS4ZGlgFACQKCHpBOhBWYVpdYjj0?= =?us-ascii?q?CBAIEBQIOAQEFgWchgVhwFYMngkIJGhWDOopTcoEpjh4BAQ?=
X-IronPort-AV: E=Sophos;i="5.64,437,1559520000"; d="scan'208";a="320230438"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 Aug 2019 14:48:07 +0000
Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x7REm7eW030774 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 27 Aug 2019 14:48:07 GMT
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 27 Aug 2019 09:48:07 -0500
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 27 Aug 2019 09:48:06 -0500
Received: from NAM05-DM3-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 27 Aug 2019 09:48:05 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PwbgSKiW4nrsjlATwQ8wYf1NhaoWryipCa4qd7e2S6L9VPMatcG0heolxC5V4qqi1EI2r/DIw3nlUiXRu7mpzx32zgpYmFC5hgrJ/Gs6ZnP8GGuuFlgOF+KRwGOO4HlgFzUdKSAlTUR4ctOefLl7Gd1JKo2mjf1D7kTEwhJIt2/eK1a0XGG0kpDyNjhbbt9pkeERyEhWRAW0J3lab+uJl5udiHO6MkLDDaPrpPdDVS5DPnsxsspBa7WJe7MM3dSG3zrUoeZpHNrzkYk3YkJA7XaGdz6OOXArbrh3l97W6YhD8fA2PcAgyFhmhyAvGxNCNkXn+3lEWx3o/ZyXfgu28A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wDOJWji19LkY2PV6ekunMU02T7YW814u/tOh710SBpQ=; b=MBEMNS/OEMaVKGltLLxWsMKu0auBRxHE681rpzv+TV1xGTozCfIu+yGwbgr6QuczzWg91X8SC+Ngb2nGtI0il8vDCEMNsebQhFB9yu0xoRRwPHVjMznKqfcMZZBfZPhzIHtqV8YibUtUbjGi30oqd8YwOiDYZocfbfdMEUla0L4ouVlZ+LXgvLimojClUmxMvEZzYL5fKRlst9ApX+0h6Vmeo08c6UBhdSyQBv6nQsTgyCOwsqWco2KPT+1ajPg6ORozJV5Q28VR3SWTqPO44dNAJjrP0GvNDb/OuDAr3OloQG5t7Umfjw44funON7lx+vG5TEXs94c1RNSYjfmXUA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wDOJWji19LkY2PV6ekunMU02T7YW814u/tOh710SBpQ=; b=ejDgvkenkwoGojSEB5WUvGEs52W5epIHHp5C/2vIpBM/8+bCPjGM7AS8CEspYhtjJ1jwLJesWbNJL+0rFSCeAIUNByjKYtl+h3awJ/8NUjJQ51l3JgqLXMzrwSYcyf7HSYubGXrkzBIIiOWHj/xCdiEq+BIrls890hl7ObSnvqc=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB4431.namprd11.prod.outlook.com (52.135.37.207) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2199.21; Tue, 27 Aug 2019 14:48:05 +0000
Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::89cf:9d:8a75:266e]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::89cf:9d:8a75:266e%3]) with mapi id 15.20.2199.021; Tue, 27 Aug 2019 14:48:04 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Tero Kivinen <kivinen@iki.fi>
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>
Thread-Topic: [6tisch] Roman Danyliw's No Objection on draft-ietf-6tisch-architecture-24: (with COMMENT)
Thread-Index: AQHVXNeVMmWEojT2uEyImDrP7NUoWacPDjKw
Date: Tue, 27 Aug 2019 14:47:52 +0000
Deferred-Delivery: Tue, 27 Aug 2019 14:47:40 +0000
Message-ID: <MN2PR11MB3565E6A131CEFBE8DD6E395CD8A00@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> <23909.10610.552936.793775@fireball.acr.fi>
In-Reply-To: <23909.10610.552936.793775@fireball.acr.fi>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com;
x-originating-ip: [2001:420:44f3:1300:8170:98a7:7988:d19d]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 9c44c6cb-57af-4dde-2515-08d72afd915a
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB4431;
x-ms-traffictypediagnostic: MN2PR11MB4431:
x-microsoft-antispam-prvs: <MN2PR11MB44310B0FCCA2CF5AAB8576C8D8A00@MN2PR11MB4431.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0142F22657
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(136003)(376002)(39860400002)(396003)(346002)(199004)(189003)(13464003)(6916009)(7736002)(86362001)(6116002)(71190400001)(71200400001)(256004)(14444005)(33656002)(5660300002)(52536014)(2906002)(66574012)(7696005)(478600001)(76116006)(66946007)(14454004)(55016002)(76176011)(53546011)(6506007)(229853002)(25786009)(54906003)(6436002)(316002)(99286004)(66556008)(66476007)(66446008)(8676002)(8936002)(46003)(81166006)(81156014)(486006)(11346002)(446003)(476003)(53936002)(9686003)(186003)(6246003)(102836004)(64756008)(305945005)(4326008)(6666004)(74316002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4431; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: vcmn6khGDsXLenedPXtP/amEpyCjA+AUkrViVjFxzIXOVus7jMTc/xTUP19a5IRJTME2ayXlKAUexevGZIO+4xkoX02VWDzJN2zuXlDjLR0Hj1RqXIe37NtJ9uws6cyu1iFm/Vm6+EfgE9MpOscxiNbCpYkAIR/eM27HVMqP3zBCSr5lmd7DvR5DqU2S8fQbct6vqVhKgXZKVnkMLP6jmJPMXlkNOrPnd09xS9cSDgTUxO5zm3fkCE1nFQtbC3wux4GIAwWJJM3dtJpsWREQ72BHD++2rvrt4EVijtXvvvyyNdhX98Wf8vwnj+JgvMrI7+Im63xKlbffvZuKHVpfegY8GKsS6oE+zihETqpOzvRvkPcMay3kitI/+ZnXw62BGCvnKnaqelJ1X0j1FGG/fES60ojW/ACxY6GxWy098YQ=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 9c44c6cb-57af-4dde-2515-08d72afd915a
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Aug 2019 14:48:04.8401 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: plNdJloHfDDwsPT0tkN1fPIhDxE9UKCVW6himUQv8peFGQf3n044rXUqp9euESI3RYkJQzUrfUrwj8pf+U8aYQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4431
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com
X-Outbound-Node: rcdn-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/XS1R6ffPf0cOm_79SwvSM1nKH8k>
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 14:48:13 -0000


All the best,

Pascal

> -----Original Message-----
> From: Tero Kivinen <kivinen@iki.fi>
> Sent: mardi 27 août 2019 15:01
> To: Pascal Thubert (pthubert) <pthubert@cisco.com>
> Cc: Roman Danyliw <rdd@cert.org>rg>; The IESG <iesg@ietf.org>rg>; Benjamin
> Kaduk <kaduk@mit.edu>du>; shwetha.bhandari@gmail.com; 6tisch@ietf.org;
> 6tisch-chairs@ietf.org; draft-ietf-6tisch-architecture@ietf.org
> 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