Re: [6tisch] Benjamin Kaduk's Discuss on draft-ietf-6tisch-minimal-security-13: (with DISCUSS and COMMENT)

Mališa Vučinić <> Tue, 10 December 2019 09:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 64AB4120868; Tue, 10 Dec 2019 01:44:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.039
X-Spam-Status: No, score=-7.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.14, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eDtWlyhsNPhI; Tue, 10 Dec 2019 01:44:26 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A56B6120837; Tue, 10 Dec 2019 01:44:25 -0800 (PST)
X-IronPort-AV: E=Sophos;i="5.69,299,1571695200"; d="scan'208";a="332659090"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Dec 2019 10:44:23 +0100
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=?= <>
In-Reply-To: <>
Date: Tue, 10 Dec 2019 10:44:22 +0100
Cc: The IESG <>, 6tisch-chairs <>, Pascal Thubert <>,,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Benjamin Kaduk <>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <>
Subject: Re: [6tisch] Benjamin Kaduk's Discuss on draft-ietf-6tisch-minimal-security-13: (with DISCUSS and COMMENT)
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" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 10 Dec 2019 09:44:28 -0000

I’ve just published -15 incorporating the remaining feedback from your COMMENT points. I also moved RFC5869 to normative references, we forgot to do this in the previous revision. Take a look and let me know if you see anything out of the ordinary.


> On 9 Dec 2019, at 19:21, Benjamin Kaduk <> wrote:
> Whoops, this got lost in my inbox; thanks for the (out-of-band) reminder.
> Luckily, basically all of it is include in the -14 and looks good, so I
> have very little left to say :)
> On Thu, Nov 07, 2019 at 05:23:37PM +0100, Mališa Vučinić wrote:
>> Many thanks for the in-depth review. In this email I am responding inline to most of the COMMENT points, in order to converge on those first. For the rest, I created bitbucket issues that we will discuss as part of the WG meeting in Singapore and get back to you.
>> The resulting changes discussed here can be found at:
>> <>
>> The list of remaining issues is available at:
>> <>
>> Mališa
>>> On 31 Oct 2019, at 07:24, Benjamin Kaduk via Datatracker <> wrote:
>> …
>>> Section 10
>>>  scanning and device-specific vulnerability exploitation.  Since the
>>>  join process occurs rarely compared to the network lifetime, long-
>>>  term threats that arise from using EUI-64 as the pledge identifier
>>>  are minimal.  In addition, the Join Response message contains a short
>>> I suspect I just failed to internalize things properly, but isn't the
>>> pledge identifier used with the network IPv6 prefix to form the global
>>> IPv6 address of the joined node?  So in that sense, using the EUI-64 as
>>> the pledge ID transfers into the long-lived address and the privacy
>>> threats are long-term as well.
>> Not necessarily. If the short identifier is returned as part of the join, the pledge can configure its IPv6 address using that. 
> But it might happen sometimes?  We could probably still mention the privacy
> consideration for that case.
>>>  Once the join process completes, the new node uses the short
>>>  addresses for all further layer 2 (and layer-3) operations.  This
>>> My understanding is that this is the usual case but not strictly
>>> required by any protocol spec.
>> That’s correct, we don’t go into this sort of configuration description in minimal-security.
> (I was trying to say that "the new node uses the short address for all
> further" is declarative, but may not be 100% true.  That said, this is only
> a COMMENT, so I'm not going to follow up on anything.)
>>>  reduces the aforementioned privacy risks as the short layer-2 address
>>>  (visible even when the network is encrypted) is not traceable between
>>>  locations and does not disclose the manufacturer, as is the case of
>>> Why is it not traceable between locations?
>> Because the assumption is that each network will assign a different short identifier to the pledge, with the identifiers being uncorrelated among networks and therefore not traceable. Does that make sense?
> Ah, I was reading this as being different locations within the same
> network.  If different locations necessitate different networks, then I
> agree.
>>> Section 13.2
>>> I agree with Barry that RFC 8505 is probably more appropriately
>>> categorized as a normative reference, and further suggest doing so for
>>> draft-ietf-core-stateless, IEEE802.15.4, and RFC 5869.
>> Done by Michael on another thread.
> (I didn't find discussion of RFC 5869, but may have been sloppy in my
> search.)
> Thanks!
> -Ben