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

Mališa Vučinić <malisa.vucinic@inria.fr> Tue, 10 December 2019 09:44 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 64AB4120868; Tue, 10 Dec 2019 01:44:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.039
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eDtWlyhsNPhI; Tue, 10 Dec 2019 01:44:26 -0800 (PST)
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 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 wifi-eduroam-85-128.paris.inria.fr ([128.93.85.128]) by mail3-relais-sop.national.inria.fr 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=?= <malisa.vucinic@inria.fr>
In-Reply-To: <20191209182141.GH13890@kduck.mit.edu>
Date: Tue, 10 Dec 2019 10:44:22 +0100
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
Content-Transfer-Encoding: quoted-printable
Message-Id: <BB1CBA79-8EC4-41A8-A83E-6AB1024CB688@inria.fr>
References: <157250308434.32464.3300056120615958441.idtracker@ietfa.amsl.com> <2FDCD14C-AC9E-4577-9090-A43452B62020@inria.fr> <20191209182141.GH13890@kduck.mit.edu>
To: Benjamin Kaduk <kaduk@mit.edu>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/jfHpXBdq1eLlIRTbt4lmKHzLXkg>
Subject: Re: [6tisch] Benjamin Kaduk's Discuss on draft-ietf-6tisch-minimal-security-13: (with DISCUSS and COMMENT)
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: 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.

Mališa

> On 9 Dec 2019, at 19:21, Benjamin Kaduk <kaduk@mit.edu> 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:
>> 
>> https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/bb94ea9108855f99ad9ac11bdf8d2d7ea7d5f7a6 <https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/bb94ea9108855f99ad9ac11bdf8d2d7ea7d5f7a6>
>> 
>> The list of remaining issues is available at:
>> 
>> https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/issues?status=new&status=open <https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/issues?status=new&status=open>
>> 
>> Mališa
>> 
>> 
>>> On 31 Oct 2019, at 07:24, Benjamin Kaduk via Datatracker <noreply@ietf.org> 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