Re: [6tisch] draft-tiloca-6tisch-robust-scheduling-01 --- rekeying permutation key

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Thu, 04 April 2019 14:59 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 0B9911204AE; Thu, 4 Apr 2019 07:59:52 -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=iTJzuj6O; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=d2QKhp3S
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 L6lZ_eJlDpoy; Thu, 4 Apr 2019 07:59:49 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FDC51205D0; Thu, 4 Apr 2019 07:59:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7074; q=dns/txt; s=iport; t=1554389989; x=1555599589; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=pxLWOYAll9Ci7o4Wc5uyu1b7AYyAjqKrI1G5fBwMBPA=; b=iTJzuj6OMlt6PV5+N/lvIFLe/DEb/wWOAfwAPNnvY/FDEEeSJVI+LYk4 GvsjMhna4SE+MB/O5wu2EdtG5Mw6T4tYhwy+59uW+sO6182L7wfyQjbor Xlvu9lFElRcg1iPSA4JxatYTME3zmsW8gNfZj1tYyetd/EznwAryShYaB o=;
IronPort-PHdr: =?us-ascii?q?9a23=3Abh5O4R0PhecAjq1ssmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxKGt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSw?= =?us-ascii?q?dDjMwXmwI6B8vQEVH7MfTndTASF8VZX1gj9Ha+YgBY?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ATAAB3G6Zc/5pdJa1lGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUwIBAQEBAQsBgT1QA2hUIAQLJwqEBINHA48igleXFYE?= =?us-ascii?q?uFIEQA1QOAQElB4FLgnUCF4U2IjYHDQEBAwEBCQEDAm0cDIVKAQEBAQMjEQw?= =?us-ascii?q?BATcBCwICAgEIEQQBAQECAhEVAgICGRcVCAgCBAENBQiDG4FdAxUBAgyifAK?= =?us-ascii?q?KFHGBL4J5AQEFhQoYggwDBQWBBiUBiGiCLR0XgUA/gRFGgkw+gmEBAQIBgRl?= =?us-ascii?q?HBRAjBYJLMYImijWCWZgDXAkCh36BEIsEggWGFINchFCECoNWh3mGHI1UAgQ?= =?us-ascii?q?CBAUCDgEBBYFWAi+BVnAVgyeCCgsYFIM4hRSBLYQScgELgRyMcAIkBAOBAQG?= =?us-ascii?q?BHgEB?=
X-IronPort-AV: E=Sophos;i="5.60,308,1549929600"; d="scan'208";a="254394144"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 04 Apr 2019 14:59:48 +0000
Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x34Exl6T028733 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 4 Apr 2019 14:59:48 GMT
Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 4 Apr 2019 09:59:46 -0500
Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 4 Apr 2019 09:59:46 -0500
Received: from NAM04-SN1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 4 Apr 2019 09:59:46 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pxLWOYAll9Ci7o4Wc5uyu1b7AYyAjqKrI1G5fBwMBPA=; b=d2QKhp3SdRDg8PB6MEJnJ3cA8kkRWEZFxWV6bvLpgR+22u4MT15vuby3T6P4bs5dLeDpaS89HCxJNgrvj3lbbFIl9so2Jo+WyrQ6vxrP/GVPIB/R3ba8gEm0+Oflb4DpiH31Qc/hbStm1b8wJlL8XTegbYIFUgrVopph2fuPflw=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB3678.namprd11.prod.outlook.com (20.178.252.94) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.20; Thu, 4 Apr 2019 14:59:45 +0000
Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::975:4644:7891:e2b1]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::975:4644:7891:e2b1%3]) with mapi id 15.20.1750.017; Thu, 4 Apr 2019 14:59:45 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Marco Tiloca <marco.tiloca@ri.se>, Michael Richardson <mcr+ietf@sandelman.ca>, "6tisch@ietf.org" <6tisch@ietf.org>
CC: "draft-tiloca-6tisch-robust-scheduling@ietf.org" <draft-tiloca-6tisch-robust-scheduling@ietf.org>
Thread-Topic: [6tisch] draft-tiloca-6tisch-robust-scheduling-01 --- rekeying permutation key
Thread-Index: AQHU6rTJv39yIIxOMkqd9je8yGJvzaYsFBsw
Date: Thu, 4 Apr 2019 14:59:40 +0000
Deferred-Delivery: Thu, 4 Apr 2019 14:58:45 +0000
Message-ID: <MN2PR11MB3565A88548C3B98F6427F559D8500@MN2PR11MB3565.namprd11.prod.outlook.com>
References: <5427.1554253601@localhost> <6ec51921-6dd6-78d4-9b5d-bde9ad40b35c@ri.se>
In-Reply-To: <6ec51921-6dd6-78d4-9b5d-bde9ad40b35c@ri.se>
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.45]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b851d304-6829-4b6d-16f4-08d6b90e2d25
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:MN2PR11MB3678;
x-ms-traffictypediagnostic: MN2PR11MB3678:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: <MN2PR11MB3678714F79D9CACA99FAFFAAD8500@MN2PR11MB3678.namprd11.prod.outlook.com>
x-forefront-prvs: 0997523C40
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(366004)(39860400002)(396003)(346002)(136003)(495844002)(199004)(189003)(13464003)(84114002)(81156014)(186003)(6306002)(105586002)(305945005)(76176011)(6246003)(11346002)(486006)(66066001)(14454004)(476003)(446003)(966005)(4326008)(52536014)(102836004)(106356001)(8936002)(53546011)(6506007)(97736004)(25786009)(53936002)(68736007)(26005)(478600001)(5660300002)(9686003)(55016002)(33656002)(86362001)(256004)(71190400001)(71200400001)(229853002)(74316002)(316002)(6436002)(8676002)(81166006)(110136005)(2906002)(14444005)(66574012)(2501003)(99286004)(6666004)(7696005)(3846002)(6116002)(7736002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3678; 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: Ot3QOW8lQsJEMCM/dsmaRU9KOysYjVjaQhrhT4vaBkewsbKr2QWQskfOmGKTL3hlkNG00GeoolPuj3eyiKZ+yQaHsUJc4VvyeHRzZHZzn+5goa4MihQ+dBapc8jZE/byRV+p15IGmlYxc7Jtcjsm+8Bgb7U954LpL0hfeBXuG3DgOAmAiR9g82zNOe1ekqgO/aHv/X7h0t9oxl7TzHjqtgM9/in8ol8sYrZpnPdotggaVAiqJHhLOxVEQc36L/szc52U5gjScoGwtqEGJAFr94uBufv88OAqFdkG1X+xuI/v5gJLQq/KKpSqcnyL6vNfL3afmOc7ufmEeqzzD7vwf4wLD6id0P5HQ8kASWoxsSzf4LVGio9HCQYK/TPpq9vt1+MHY4zPbwyihbtA11ZgKzvi9Ctc8uMgoaQP8co6bAw=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: b851d304-6829-4b6d-16f4-08d6b90e2d25
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Apr 2019 14:59:45.4788 (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-Transport-CrossTenantHeadersStamped: MN2PR11MB3678
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.18, xch-rcd-008.cisco.com
X-Outbound-Node: rcdn-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/a-SyZZWVluoTf-N8ky_D7Hu4lis>
Subject: Re: [6tisch] draft-tiloca-6tisch-robust-scheduling-01 --- rekeying permutation key
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: Thu, 04 Apr 2019 14:59:52 -0000

I concur with Michael, this is interesting work.

Note that 
1) It is possible to commute only a subset of the channel offsets at a given time offset. This reduces the number of nodes that need to know about the swap and thus the exposure to a leakage.
2) security is not the only reason why swapping is useful. As you know, under constant conditions, pairs of nodes will suffer from multipath fading on some channels and not on others. Once this has been observed, it is possible to do a selective swap to avoid the particular channels that affect a particular pair of nodes. 
3) I have IPR on that sort of stuff (USPTO 9,673,856); it is not exactly the method you propose but close enough. Just in case I'll ask to publish terms.

All the best,

Pascal

> -----Original Message-----
> From: 6tisch <6tisch-bounces@ietf.org> On Behalf Of Marco Tiloca
> Sent: jeudi 4 avril 2019 09:05
> To: Michael Richardson <mcr+ietf@sandelman.ca>ca>; 6tisch@ietf.org
> Cc: draft-tiloca-6tisch-robust-scheduling@ietf.org
> Subject: Re: [6tisch] draft-tiloca-6tisch-robust-scheduling-01 --- rekeying
> permutation key
> 
> Hi Michael,
> 
> Thank you very much for your review!
> 
> We'll definitely take into account your comments for the next version.
> 
> Please, find also some answers inline.
> 
> Best,
> /Marco
> 
> On 4/3/19 3:06 AM, Michael Richardson wrote:
> > I read draft-tiloca-6tisch-robust-scheduling-01.
> >
> > I found this to be an interesting way to both announce the schedule,
> > and yet, hide it.  Very well done.
> 
> <MT>
> Thanks!
> </MT>
> 
> >
> > I have some initial comment about the section 3.1 about the adversary.
> > I wondered about why someone would do this.  What's the benefit.
> >
> > It occured to me that an important point about the selective jamming
> > is that an attacker can mess with a competitors network while still
> > permitting their own network to operate!  That might be worth adding.
> 
> <MT>
> It's a very good point! We'll add this as an attack motivation in Section 3.1.
> </MT>
> 
> > The document seems well written, although I'd like to have some
> > example keys and show how they permute things in practice so that
> > implementors can validate their work.
> 
> <MT>
> Right, we will produce an example, possibly as an Appendix referred at the end
> of Section 4.
> </MT>
> 
> 
> > The additions to CoJP seems well done, I'm so glad we changed that to
> > a hash From an array :-)
> >
> > If the permutation is replaced whenever the network key is changed,
> > which means that the permutation is going to change!  This means that
> > some nodes could be on the new permutation while others are on the old.
> >
> > A thought to deal with this is that the new permutation is not used
> > until the node switches to the new keys.  EXCEPT that the adjacent
> > nodes will now not be listening at the right time, won't hear traffic encrypted
> with the new
> > key, and won't change over themselves.   Authenticated enhanced beacons
> would
> > perhaps help here.  Maybe I'm wrong about this problem.
> 
> <MT>
> This seems to deserve some more text in the Security Considerations of
> Section 6.2, such as the following points.
> 
> The new link keys and permutation keys are expected to be distributed
> together, just like for the described provisioning through the CoJP Join
> Response, possibly through the same procedure described in [1].
> 
> After a rekeying process is completed, a node should indeed start using the
> new permutation keys once switched to the new link keys only, i.e.
> after it has discarded the old key material as per the handling of the "link-layer
> key set" in [2].
> 
> If a node A discards the old key material (considerably) before a node B, they
> will be temporarily unaligned. That is, node B would temporarily secure
> outgoing messages still using the old key material [2] that A does not own
> anymore, and would still permute its schedule the old way.
> 
> Eventually, B will also discard the old key material, e.g. after receiving and
> successfully security processing an incoming message secured with the new
> key material [2], of course though while still over its old-fashion-permuted
> schedule. Here enhanced beacons authenticated with the new key material
> seem to help. Also, a local upper bound can be enforced through a parameter
> similar to COJP_REKEYING_GUARD_TIME [2].
> Then, the two nodes will be aligned again on both processing secure messages
> and permuting their schedule.
> 
> 
> What do you think?
> 
> 
> [1]
> https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-09#section-8.2
> [2]
> https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-09#section-8.4
> 
> </MT>
> 
> > --
> > Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
> > -= IPv6 IoT consulting =-
> 
> --
> Marco Tiloca
> Ph.D., Senior Researcher
> 
> RISE Research Institutes of Sweden
> Division ICT
> Isafjordsgatan 22 / Kistagången 16
> SE-164 40 Kista (Sweden)
> 
> Phone: +46 (0)70 60 46 501
> https://www.ri.se
>