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

Marco Tiloca <marco.tiloca@ri.se> Thu, 04 April 2019 07:04 UTC

Return-Path: <marco.tiloca@ri.se>
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 A978A1203A5; Thu, 4 Apr 2019 00:04:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=risecloud.onmicrosoft.com
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 4t1rjnL4DP_6; Thu, 4 Apr 2019 00:04:44 -0700 (PDT)
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10084.outbound.protection.outlook.com [40.107.1.84]) (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 B1E85120004; Thu, 4 Apr 2019 00:04:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=RISEcloud.onmicrosoft.com; s=selector1-ri-se; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QQIFSXlobe2aXv+Y2eK2hozhwcotnOuO9codNeBjLBU=; b=Z4jUN2CKy1Y+N3t809Rv8T/klDI7kGFN02pMOHNhdohsA8osprcCd7FlnXuXi16R1kgdoBaapqJxK0z9Vot5J5yzMmSXaLmTW3Zhfgl+4h1fYvaQVY2MdQqyKySBVlSOtFM5y6Y4pxSWWQ2j5osAi7YIYiG6VBriykKtuVclGb4=
Received: from DB6P18901CA0015.EURP189.PROD.OUTLOOK.COM (2603:10a6:4:16::25) by HE1P18901MB0106.EURP189.PROD.OUTLOOK.COM (2603:10a6:3:9b::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.16; Thu, 4 Apr 2019 07:04:40 +0000
Received: from AM5EUR02FT056.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e1e::209) by DB6P18901CA0015.outlook.office365.com (2603:10a6:4:16::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.15 via Frontend Transport; Thu, 4 Apr 2019 07:04:40 +0000
Authentication-Results: spf=pass (sender IP is 194.218.146.197) smtp.mailfrom=ri.se; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=ri.se;
Received-SPF: Pass (protection.outlook.com: domain of ri.se designates 194.218.146.197 as permitted sender) receiver=protection.outlook.com; client-ip=194.218.146.197; helo=mail.ri.se;
Received: from mail.ri.se (194.218.146.197) by AM5EUR02FT056.mail.protection.outlook.com (10.152.9.107) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.20.1750.20 via Frontend Transport; Thu, 4 Apr 2019 07:04:40 +0000
Received: from [10.8.1.7] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Thu, 4 Apr 2019 09:04:39 +0200
To: Michael Richardson <mcr+ietf@sandelman.ca>, <6tisch@ietf.org>
CC: <draft-tiloca-6tisch-robust-scheduling@ietf.org>
References: <5427.1554253601@localhost>
From: Marco Tiloca <marco.tiloca@ri.se>
Openpgp: preference=signencrypt
Autocrypt: addr=marco.tiloca@ri.se; prefer-encrypt=mutual; keydata= mQENBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Z aRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt 0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0 Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+ NrSetJlljT0QOXrXMGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEB AAG0Nk1hcmNvIFRpbG9jYSAobWFyY28udGlsb2NhQHJpLnNlKSA8bWFyY28udGlsb2NhQHJp LnNlPokBNwQTAQgAIQUCWkAnkAIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRDuJmS0 DljaQwEvCACJKPJIPGH0oGnLJY4G1I2DgNiyVKt1H4kkc/eT8Bz9OSbAxgZo3Jky382e4Dba ayWrQRFen0aLSFuzbU4BX4O/YRSaIqUO3KwUNO1iTC65OHz0XirGohPUOsc0SEMtpm+4zfYG 7G8p35MK0h9gpwgGMG0j0mZX4RDjuywC88i1VxCwMWGaZRlUrPXkC3nqDDRcPtuEGpncWhAV Qt2ZqeyITv9KCUmDntmXLPe6vEXtOfI9Z3HeqeI8OkGwXpotVobgLa/mVmFj6EALDzj7HC2u tfgxECBJddmcDInrvGgTkZtXEVbyLQuiK20lJmYnmPWN8DXaVVaQ4XP/lXUrzoEzuQENBFSN eRUBCACWmp+k6LkY4/ey7eA7umYVc22iyVqAEXmywDYzEjewYwRcjTrH/Nx1EqwjIDuW+BBE oMLRZOHCgmjo6HRmWIutcYVCt9ieokultkor9BBoQVPiI+Tp51Op02ifkGcrEQNZi7q3fmOt hFZwZ6NJnUbA2bycaKZ8oClvDCQj6AjEydBPnS73UaEoDsqsGVjZwChfOMg5OyFm90QjpIw8 m0uDVcCzKKfxq3T/z7tyRgucIUe84EzBuuJBESEjK/hF0nR2LDh1ShD29FWrFZSNVVCVu1UY ZLAayf8oKKHHpM+whfjEYO4XsDpV4zQ15A+D15HRiHR6Adf4PDtPM1DCwggjABEBAAGJAR8E GAECAAkFAlSNeRUCGwwACgkQ7iZktA5Y2kPGEwf/WNjTy3z74vLmHycVsFXXoQ8W1+858mRy Ad0a8JYzY3xB7CVtqI3Hy894Qcw4H6G799A1OL9B1EeA8Yj3aOz0NbUyf5GW+iotr3h8+KIC OYZ34/BQaOLzdvDNmRoGHn+NeTzhF7eSeiPKi2jex+NVodhjOVGXw8EhYGkeZLvynHEboiLM 4TbyPbVR9HsdVqKGVTDxKSE3namo3kvtY6syRFIiUz5WzJfYAuqbt6m3TxDEb8sA9pzaLuhm fnJRc12H5NVZEZmE/EkJFTlkP4wnZyOSf/r2/Vd0iHauBwv57cpY6HFFMe7rvK4s7ME5zctO Ely5C6NCu1ZaNtdUuqDSPA==
Message-ID: <6ec51921-6dd6-78d4-9b5d-bde9ad40b35c@ri.se>
Date: Thu, 4 Apr 2019 09:04:34 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <5427.1554253601@localhost>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="y5PMUyvinTJhfNNODgcOTDdKAmFXnGipz"
X-Originating-IP: [10.116.0.226]
X-ClientProxiedBy: sp-mail-2.sp.se (10.100.0.162) To sp-mail-2.sp.se (10.100.0.162)
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:194.218.146.197; IPV:NLI; CTRY:SE; EFV:NLI; SFV:NSPM; SFS:(10009020)(396003)(346002)(136003)(39860400002)(376002)(2980300002)(495844002)(189003)(199004)(81166006)(126002)(64126003)(106002)(305945005)(7736002)(478600001)(44832011)(11346002)(486006)(31686004)(58126008)(5660300002)(14444005)(16576012)(74482002)(110136005)(6246003)(5024004)(966005)(6306002)(3846002)(16586007)(6116002)(69596002)(66574012)(235185007)(68736007)(568964002)(4326008)(53936002)(476003)(356004)(2906002)(336012)(104016004)(186003)(8936002)(26005)(65806001)(53546011)(6666004)(16526019)(97736004)(2616005)(229853002)(22746008)(81156014)(22756006)(40036005)(386003)(316002)(86362001)(106466001)(8676002)(65826007)(31696002)(33964004)(446003)(65956001)(77096007)(84326002)(71190400001)(36756003)(21480400003)(76176011); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1P18901MB0106; H:mail.ri.se; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; MX:1; A:1;
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 86a66e4b-b086-4a49-0bc1-08d6b8cbce7d
X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600139)(711020)(4605104)(4709054)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:HE1P18901MB0106;
X-MS-TrafficTypeDiagnostic: HE1P18901MB0106:
X-Microsoft-Antispam-PRVS: <HE1P18901MB01061101E0BB8DA2AC651CA299500@HE1P18901MB0106.EURP189.PROD.OUTLOOK.COM>
X-Forefront-PRVS: 0997523C40
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam-Message-Info: yPiDib9IX6ceQelpq0b7LAA9cfLwkikBBw11LrXPNEoh2bDq/zJDPWUq7Rvu7r46fxqrnJzgsifgeCCpMyN4JbBl3L/2Dmz7++PBGFXC4+xeDp3etHNMPzGskh/hYVr1dvnYMcdgBCaOlrsbOCe6GtMRtiafmMm7rMvrg+z9xMWv3z+/h+eSMsgbZ8jTUqA2HjoclXK1RMIC8foL3FrqbHEDefjYNn62b2e+tUtQDnRJs+ERDUMwunAoZf/YnxGDIO+BfFNpfSN8lnnyvmIB59i8IZdRGO2zNfyYgB4Y4cbg4Rh85h+Hj34IBKI4PGXZhw77FtxEI1UQBxbZ7PpJQl6Vli0AVoqL5IoAx0MxGe+qFgDDf+RDeinxt3p/k1w4YeSVQ7CGN8uhkpxJghnQ51lIMnenOxmbSMnzD7zFQrE=
X-OriginatorOrg: ri.se
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Apr 2019 07:04:40.0446 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 86a66e4b-b086-4a49-0bc1-08d6b8cbce7d
X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=5a9809cf-0bcb-413a-838a-09ecc40cc9e8; Ip=[194.218.146.197]; Helo=[mail.ri.se]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1P18901MB0106
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/MJ6LwQoeQ_eZUuIUzctfCa48WvI>
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 07:04:49 -0000

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