Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= <malisa.vucinic@inria.fr>
In-Reply-To: <157023324915.1400.10416689027865506912@ietfa.amsl.com>
Date: Mon, 7 Oct 2019 17:38:41 +0200
Cc: ops-dir@ietf.org, 6tisch <6tisch@ietf.org>, ietf@ietf.org,
 draft-ietf-6tisch-minimal-security.all@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <91540EE6-E74D-4ECA-9E54-9B5E35FA5937@inria.fr>
References: <157023324915.1400.10416689027865506912@ietfa.amsl.com>
To: Linda Dunbar <linda.dunbar@futurewei.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/J-9_1GXZunKlcnlfJn33Ap6LECg>
Subject: Re: [6tisch] Opsdir last call review of
 draft-ietf-6tisch-minimal-security-12
Precedence: list

Dear Linda,

Many thanks for your review. Please find the responses inline.

Kind regards,
Mali=C5=A1a

> On 5 Oct 2019, at 01:54, Linda Dunbar via Datatracker =
<noreply@ietf.org> wrote:
>=20
> Reviewer: Linda Dunbar
> Review result: Has Nits
>=20
> Reviewer: Linda Dunbar
> Review result: Has Nits  & with comment
>=20
> 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.
>=20
> This document is written very clear, specifying a framework for a new =
device to
> securely join a 6TiSCH network.

>=20
> 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=E2=80=A6What 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".
>=20
> Can you use a different acronym because ASN has been widely used in =
networking
> as the Autonomous System Number.

ASN for "Absolute slot number=E2=80=9D 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.
>=20
> Thank you.
>=20
> Linda Dunbar
>=20
>=20
> _______________________________________________
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch