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

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Wed, 28 August 2019 09:16 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 8DCB9120096; Wed, 28 Aug 2019 02:16: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=UThp+SlQ; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=UvxpR6cp
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 rh0OPBWpK00W; Wed, 28 Aug 2019 02:16:09 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 671A7120086; Wed, 28 Aug 2019 02:16:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4515; q=dns/txt; s=iport; t=1566983769; x=1568193369; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=couBur83x4qbSqAkGA0dKl3+NyYSuGG/qEybUpI17Oo=; b=UThp+SlQPVWifh5+Vm2tiN7qjWSQ9aG74JHZeGmklVx5rL+/bq3R8Z6j gUL/otf7VZFkbbfRnlyLpk2epkssewDZMhDjbt8TWZjw2IYvHL1n48hdb JndIZDNmHIkjKfpRePUwZhZ7UxuiRYapIYoP8JX0+3JCQ8JPjQDT4wfZ0 8=;
IronPort-PHdr: 9a23:6IPGGhdFd7AoUzVyv1hP02B3lGMj4e+mNxMJ6pchl7NFe7ii+JKnJkHE+PFxlwGQD57D5adCjOzb++D7VGoM7IzJkUhKcYcEFnpnwd4TgxRmBceEDUPhK/u/dzA6Ac5PTkNN9HCgOk8TE8H7NBXf
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0C0AABkRWZd/4cNJK1mGgEBAQEBAgEBAQEHAgEBAQGBZ4FFUAOBQyAECyoKh14DinRNgg+JYI4JglIDVAkBAQEMAQEtAgEBgUuCdAKCTCM4EwIKAQEEAQEBAgEGBG2FLgyFSgEBAQQSLgEBNwELBAIBCBEBAwEBAS4hERcGCAIEAQkEBQgahGsDHQECn3cCgTiIYYIlgnsBAQWFBg0LghYJgTSJLoIsHRiBQD+BEUaBTn4+ghqCFhaDO4Imjm6GR5YCQAkCgh6QUoQVgjKHMI51jWyJbo4+AgQCBAUCDgEBBYFnIYFYcBWDJ4JCCRoVgzqKU3KBKYs0gTABgSABAQ
X-IronPort-AV: E=Sophos;i="5.64,440,1559520000"; d="scan'208";a="315266558"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 28 Aug 2019 09:16:08 +0000
Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x7S9G8ci024976 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 28 Aug 2019 09:16:08 GMT
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 28 Aug 2019 04:16:08 -0500
Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 28 Aug 2019 05:16:06 -0400
Received: from NAM05-CO1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 28 Aug 2019 04:16:06 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nlzCbG3XgL0wr1QubyhuDdLUhoXNf3N0E6WoAg8Lglujv7Ku8xNCjFEF07qZ+p+hzhGVz/uuhl0HEvXV3U6OXslAVhRzTAbcABeykgleXXgrzRKfmLSovAf7hu1xJtDsgiKynkVxePjG9Ac6iYaLkvdev/0cVyUECqv6a5dtKIM9MeSPBCMND3kXIMLs1cqM9JaKJREy3HNpcn4vC1vTzfG9myABts6C1kdgQgz2ki10/3bIPNh5DWuua593hi5eyX+W2HBZDudRJg80KYZQYMfrccT52Mxu/vutg2edev8SyGdwHhqjLgilayIoPi76yY9kwG1cy/K1RD2nDdkFBw==
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=hiWa16cEa6H7xFthSn3aOqnw7VEuly0tdZ3EW4kFu08=; b=NvWFQALi486KI0c+PCtOherGMyaVCTUPq+KvQE66nKCdOD33+WlNC2pYvTC7coHI9iV6oSDMSB8Qb8Sxz4w/kHSdYouUJxLutEsfO8KbDeufAiYPKfieQViIWVLCIXqnRS0xKpfSSxlQNbOtNEEVDwYIDIPXTg6f7G9NVcBaQrSQDTRbueGLLX/XzdtgeYVhY/05ZXZHRY+Z7sXI0rzwpRigdKI8D2YdyFtWzoxd/FNPEu25bQ2AEhkEPx2Uw1H/WG0WUzKMBDdeV2jWxNPeNHG1mKLYlFd8hHMrYtjeGmrRiB8Q119wBMAPn+DR55gxC0DUnoEm5iwk0rxaaWKOgg==
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=hiWa16cEa6H7xFthSn3aOqnw7VEuly0tdZ3EW4kFu08=; b=UvxpR6cpMtAutzP0aeDvOU9EkiBlP7rSjUCHCsvszT1hiewRjRIf71zWrFuv2Zh2gQvnZH8WJDaZHmTKOWU0MYTIlzL2MjrSxq3VT2NGNHHPRgFiWrdfqKNjIDoqO1LZ0C0PvoxTLvSCSdKwRVccA0rzKbKiF5i5ve9wBwYIhqo=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB3952.namprd11.prod.outlook.com (10.255.181.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2199.21; Wed, 28 Aug 2019 09:16: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; Wed, 28 Aug 2019 09:16:05 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>, Tero Kivinen <kivinen@iki.fi>
CC: 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>
Thread-Topic: [6tisch] Roman Danyliw's No Objection on draft-ietf-6tisch-architecture-24: (with COMMENT)
Thread-Index: AQHVXP7yMmWEojT2uEyImDrP7NUoWacQRYNg
Date: Wed, 28 Aug 2019 09:15:42 +0000
Deferred-Delivery: Wed, 28 Aug 2019 09:15:11 +0000
Message-ID: <MN2PR11MB35654D0C271FE2B297EECD43D8A30@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> <21458.1566927814@localhost>
In-Reply-To: <21458.1566927814@localhost>
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: [173.38.220.61]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 5ef668fb-529d-4d79-406a-08d72b985a95
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB3952;
x-ms-traffictypediagnostic: MN2PR11MB3952:
x-microsoft-antispam-prvs: <MN2PR11MB39525F5B5AF25E35384F5D6FD8A30@MN2PR11MB3952.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 014304E855
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(136003)(376002)(366004)(346002)(39860400002)(13464003)(199004)(51444003)(189003)(71190400001)(7736002)(66476007)(64756008)(66446008)(66556008)(3846002)(76116006)(52536014)(66946007)(81156014)(2906002)(54906003)(71200400001)(6666004)(5660300002)(256004)(14444005)(14454004)(305945005)(74316002)(33656002)(66574012)(66066001)(478600001)(81166006)(9686003)(26005)(486006)(86362001)(11346002)(476003)(4326008)(55016002)(446003)(6436002)(25786009)(99286004)(6116002)(76176011)(7696005)(229853002)(6506007)(102836004)(316002)(186003)(53936002)(6246003)(8676002)(53546011)(8936002)(110136005); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3952; 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: /PImNWDkaDHjpB/V8tkXerHODXmcV2XutJLgqYQbJMvvY2aiu53wSROWMDIPp8hJfr0gnMg9kzY8/0xt5H9N/7eVNLecaKsGyITi1CemHieYmit+KzUbf5CLRhnCFfnwNUTkWCGA/U0p9X6OA/VwARhpfQ6lriTCna3iGlbRXVmukU2FJSycqT2iDjXHIAf52+u5i/rLwtBcoOv8Q9XbwWZauftvFnRYQ8HFR+pU5zbEvN9EDa1PYemAkzpK8i+AK25S3uD0yYbeb7k+OVOiibBW6KOFjegYNNV7x78epwzfEYWGc25MgeVHeV9zxqt/kGUMzpG/l9K6hEL8lDT/7nHGm7gsV87wZ+IEUSvIPUZirFbLWKi8OrxtnzcJELrxq5C+44XZBLgsIAVgf+X5LBrjMCNb5v5oaqzGhAICiVE=
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: 5ef668fb-529d-4d79-406a-08d72b985a95
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Aug 2019 09:16:04.9249 (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: S/xb/5cVnNP4gzSZAa8CsDCTwih4Rg4jNbBCKd2HS+F1Yb5xuVB7oQoNXbn8Kt8I6R+yWexzcx1qtXkkxdxZuQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3952
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.18, xch-aln-008.cisco.com
X-Outbound-Node: alln-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/28Pa0T7ALiDx1BNH2th350a67N4>
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: Wed, 28 Aug 2019 09:16:13 -0000

With the default of 10 ms it takes 350 years to wrap ASN. That's  long memory to keep for an attacker. Modern storage technology does not last that long.

But hey, 6TiSCH is designed to be easily portable to other deterministic MAC technologies (think RAW) which would be much faster. A reasonable time slot in 802.11 ax would be below 1ms, which would take is down to 35 years. But there are alternatives:

- At some point we do not slot anymore, just provide precise time for transmission (think time-based shapers).

- If we keep resource blocks of 10ms in 5G, there will be multiple packets, so ASN will need an extension (at least an additional octet that would be signaled in band) to count the packet with a finer granularity than ASN, within the time slot.

I modified Archie based on Tero's comment to make it more abstract - just say nonce-reuse attack deferring to others on what the result of the attack can be - and indicate the 350 years. Please ssee if that's enough.

All the best,

Pascal

> -----Original Message-----
> From: Michael Richardson <mcr+ietf@sandelman.ca>
> Sent: mardi 27 août 2019 19:44
> To: Tero Kivinen <kivinen@iki.fi>
> Cc: Pascal Thubert (pthubert) <pthubert@cisco.com>; Roman Danyliw
> <rdd@cert.org>; shwetha.bhandari@gmail.com; 6tisch-chairs@ietf.org; The
> IESG <iesg@ietf.org>; 6tisch@ietf.org; draft-ietf-6tisch-architecture@ietf.org;
> Benjamin Kaduk <kaduk@mit.edu>
> Subject: Re: [6tisch] Roman Danyliw's No Objection on draft-ietf-6tisch-
> architecture-24: (with COMMENT)
> 
> 
> 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>, Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
>