Re: [6tisch] Opsdir last call review of draft-ietf-6tisch-minimal-security-12

Mališa Vučinić <malisa.vucinic@inria.fr> Fri, 11 October 2019 09:18 UTC

Return-Path: <malisa.vucinic@inria.fr>
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 C2571120043; Fri, 11 Oct 2019 02:18:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-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 Pl_cffRbG3x5; Fri, 11 Oct 2019 02:18:06 -0700 (PDT)
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (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 3C548120020; Fri, 11 Oct 2019 02:18:05 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.67,283,1566856800"; d="scan'208,217";a="322384677"
Received: from wifi-pro-82-179.paris.inria.fr ([128.93.82.179]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Oct 2019 11:18:03 +0200
From: =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= <malisa.vucinic@inria.fr>
Message-Id: <0EEA127F-FA8F-4BA2-8ED5-1614ECAC6566@inria.fr>
Content-Type: multipart/alternative; boundary="Apple-Mail=_8B5A299D-355C-4C54-B4E9-59F20B2AAE76"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Fri, 11 Oct 2019 11:18:02 +0200
In-Reply-To: <BN8PR13MB262886B2376BAD2ECBB317D985940@BN8PR13MB2628.namprd13.prod.outlook.com>
Cc: "ops-dir@ietf.org" <ops-dir@ietf.org>, 6tisch <6tisch@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "draft-ietf-6tisch-minimal-security.all@ietf.org" <draft-ietf-6tisch-minimal-security.all@ietf.org>
To: Linda Dunbar <linda.dunbar@futurewei.com>
References: <157023324915.1400.10416689027865506912@ietfa.amsl.com> <91540EE6-E74D-4ECA-9E54-9B5E35FA5937@inria.fr> <BN8PR13MB262886B2376BAD2ECBB317D985940@BN8PR13MB2628.namprd13.prod.outlook.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/lWkxabBNbepiROMoAxSHXpkwUpg>
Subject: Re: [6tisch] Opsdir last call review of draft-ietf-6tisch-minimal-security-12
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: Fri, 11 Oct 2019 09:18:09 -0000

Dear Linda,

After a second look, I noticed that the ASN acronym only had a couple of occurrences in the text. To address your comment, I replaced the occurrences of “ASN" with the expanded version “absolute slot number” without defining the acronym in our document. The changes following your review can be found at:

https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/83e751fd8c97441e0362df983dec2801b6177300 <https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/83e751fd8c97441e0362df983dec2801b6177300> 

Please let me know whether I should go ahead and upload the new version to the datatracker.

Mališa

> On 10 Oct 2019, at 18:42, Linda Dunbar <linda.dunbar@futurewei.com> wrote:
> 
> Malisa, 
> 
> Thanks for the changes. 
> 
> I didn't realize that IEEE802.15 uses ASN for completely different purpose than the IETF's ASN. Maybe add a note stating "this ASN is completely different from the BGP's ASN". 
> 
> Linda
> 
> -----Original Message-----
> From: Mališa Vučinić <malisa.vucinic@inria.fr <mailto:malisa.vucinic@inria.fr>> 
> Sent: Monday, October 07, 2019 10:39 AM
> To: Linda Dunbar <linda.dunbar@futurewei.com <mailto:linda.dunbar@futurewei.com>>
> Cc: ops-dir@ietf.org <mailto:ops-dir@ietf.org>; 6tisch <6tisch@ietf.org <mailto:6tisch@ietf.org>>; ietf@ietf.org <mailto:ietf@ietf.org>; draft-ietf-6tisch-minimal-security.all@ietf.org <mailto:draft-ietf-6tisch-minimal-security.all@ietf.org>
> Subject: Re: [6tisch] Opsdir last call review of draft-ietf-6tisch-minimal-security-12
> 
> Dear Linda,
> 
> Many thanks for your review. Please find the responses inline.
> 
> Kind regards,
> Mališa
> 
>> On 5 Oct 2019, at 01:54, Linda Dunbar via Datatracker <noreply@ietf.org> wrote:
>> 
>> Reviewer: Linda Dunbar
>> Review result: Has Nits
>> 
>> Reviewer: Linda Dunbar
>> Review result: Has Nits  & with comment
>> 
>> I am the assigned Ops area reviewer for this draft. The Ops 
>> directorate reviews all IETF documents being processed by the IESG for 
>> the IETF Chair.  Please treat these comments just like any other last call comments.
>> 
>> This document is written very clear, specifying a framework for a new 
>> device to securely join a 6TiSCH network.
> 
>> 
>> One question: the document assumes that there is pre-shared key (PSK) 
>> between the device and the controller. The Security Consideration does 
>> describe the common pitfall of  a single PSK shared among a group of 
>> devices. Is there any way to prevent it? Is it necessary to require 
>> the Key to be periodically changed?
> 
> Please note that the document mandates unique PSKs between each device and the JRC (Section 3, PSK), thus a compromise of a single device does not leak the PSK of other devices in the network. The discussion you refer to in the Security Consideration section makes an attempt to draw attention to the unsafe practices, but beyond mandating the PSK to be unique for each pledge, which is already a strong requirement, I am not sure we can do much more about it. Requiring the PSK to be periodically changed would require periodic in-situ manipulation of devices (by the 100s or even 1000s), something that is not realistically going to happen…What we could do, however, is to mandate the PSK to be changed upon device re-commissioning to a new owner, when it is likely that a device needs to be manipulated, so I would propose the following sentence be added at the end of Section 3, PSK:
> 
> NEW:
> In case of device re-commissioning to a new owner, it is REQUIRED to change the PSK.
> 
> Would that work?
> 
>> Another  suggestion:
>> Section 5.1 introduces an acronym ASN to represent "Absolute slot number".
>> 
>> Can you use a different acronym because ASN has been widely used in 
>> networking as the Autonomous System Number.
> 
> ASN for "Absolute slot number” was defined in the IEEE 802.15.4 specification and the acronym is widely used in our community. I would refrain from re-defining it as it would cause confusion, given that is already used in other documents produced by the 6TiSCH working group (RFC8180, RFC7554).
> 
>> ---
>> An autonomous system number (ASN) is a unique number that's available 
>> globally to identify an autonomous system and which enables that 
>> system to exchange exterior routing information with other neighboring autonomous systems.
>> 
>> Thank you.
>> 
>> Linda Dunbar
>> 
>> 
>> _______________________________________________
>> 6tisch mailing list
>> 6tisch@ietf.org
>> https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww <https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww>.
>> ietf.org <http://ietf.org/>%2Fmailman%2Flistinfo%2F6tisch&amp;data=02%7C01%7Clinda.dunbar
>> %40futurewei.com <http://40futurewei.com/>%7C4b48bea8289a448fc54308d74b3c7064%7C0fee8ff2a3b24018
>> 9c753a1d5591fedc%7C1%7C1%7C637060595293959400&amp;sdata=eD9OiaPzigRIqt
>> 66tBC1fANtpgzVzIX2SxldjSYwsq4%3D&amp;reserved=0