Re: [6tisch] Éric Vyncke's No Objection on draft-ietf-6tisch-minimal-security-13: (with COMMENT)

Mališa Vučinić <malisa.vucinic@inria.fr> Thu, 07 November 2019 16:23 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 BCCD512093A; Thu, 7 Nov 2019 08:23:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.898
X-Spam-Level:
X-Spam-Status: No, score=-6.898 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, URIBL_BLOCKED=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 GPgtGui2NIS6; Thu, 7 Nov 2019 08:23:25 -0800 (PST)
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (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 7212D120935; Thu, 7 Nov 2019 08:23:24 -0800 (PST)
X-IronPort-AV: E=Sophos;i="5.68,278,1569276000"; d="scan'208,217";a="410856091"
Received: from wifi-pro-82-219.paris.inria.fr ([128.93.82.219]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Nov 2019 17:23:22 +0100
From: =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= <malisa.vucinic@inria.fr>
Message-Id: <339D4935-03C8-4162-A226-8A11F3047E78@inria.fr>
Content-Type: multipart/alternative; boundary="Apple-Mail=_31C8F4A5-7BD2-4FB7-A1AC-392DBA3C8ADF"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Thu, 7 Nov 2019 17:23:22 +0100
In-Reply-To: <157251627883.30451.13074753596662856513.idtracker@ietfa.amsl.com>
Cc: The IESG <iesg@ietf.org>, 6tisch-chairs <6tisch-chairs@ietf.org>, Pascal Thubert <pthubert@cisco.com>, draft-ietf-6tisch-minimal-security@ietf.org, 6tisch@ietf.org
To: =?utf-8?Q?=C3=89ric_Vyncke?= <evyncke@cisco.com>
References: <157251627883.30451.13074753596662856513.idtracker@ietfa.amsl.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/P5DjWx0uMNDqJQknYD3m41BpOuc>
Subject: Re: [6tisch] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ie?= =?utf-8?q?tf-6tisch-minimal-security-13=3A_=28with_COMMENT=29?=
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, 07 Nov 2019 16:23:28 -0000

Dear Éric,

Many thanks for your review. You can find the responses to your comments inline and the overall diff following your review at:

https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/8e04a2e442cca81c18809b5d6e88ed0d01d012ea?at=minimal-security-14 <https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/8e04a2e442cca81c18809b5d6e88ed0d01d012ea?at=minimal-security-14>

Mališa

> On 31 Oct 2019, at 11:04, Éric Vyncke via Datatracker <noreply@ietf.org> wrote:
> 
> Éric Vyncke has entered the following ballot position for
> draft-ietf-6tisch-minimal-security-13: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal-security/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thank you for the work put into this document. The document is easy to read. I
> have a couple of comments and nits. Feel free to ignore all of them.
> 
> Regards,
> 
> -éric
> 
> == COMMENTS ==
> 
> -- Section 1 --
> Please add reference to IEEE Std 802.15.4 at first mention.

done

> 
> -- Section 1 --
> It is unclear in this section whether the PSK is per pledge (then hitting a
> scalability issue) or shared by all pledge (then having huge security risk).
> Section 3 is clearer on this but the reader would benefit by knowing this in
> section 1.

-The configuration defined in this document assumes that the pledge and the JRC share a secret cryptographic key, called PSK (pre-shared key).
+The configuration defined in this document assumes that the pledge and the JRC share a unique symmetric cryptographic key, called PSK (pre-shared key).

> -- Section 2 --
> Please consider not using "secret key" and "symmetric key" interchangeably. Esp
> as "secret key" is often used in the context of asymmetric key.

I made the change throughout the document to use the term “symmetric key” exclusively.


> 
> -- Section 3 --
> Unsure whether the text about provisionning "Physically, ..." brings anything
> useful.

If there is no strong opinion here, I left this text for now as in our opinion it gives an idea to the reader on how the provisioning can be done.


> -- Section 3 --
> Please add references to DHCPv6, GRASP, mDNS.

done


> -- Section 4.2 --
> It is unclear whether duplicate address detection should be done.

Section 5.6 of RFC8505 that we reference is clear on this that DAD needs not be done for link-local addresses. I added the following sentence to clarify this in our draft:

+As per {{RFC8505}}, there is no need to perform duplicate address detection for the link-local address.

> 
> == NITS ==
> 
> -- Section 4 --
> Please expand L2 at first mention.

done

> 
> -- Section 6.1.2 --
> I am not a native English speaker but I wonder whether the word 'convergecast'
> is well-known.

rephrased to avoid the use of the term “convergecast”. 

-Due to the convergecast nature of the DODAG, the 6LBR links are often the most congested, and from that point down there is progressively less (or equal) congestion.
+The 6LBR links are often the most congested within a DODAG, and from that point down there is progressively less (or equal) congestion.