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

Benjamin Kaduk <kaduk@mit.edu> Mon, 09 December 2019 18:21 UTC

Return-Path: <kaduk@mit.edu>
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 E6DF0120104; Mon, 9 Dec 2019 10:21:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 JpL51seIggmH; Mon, 9 Dec 2019 10:21:49 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 C0C7D12004F; Mon, 9 Dec 2019 10:21:48 -0800 (PST)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xB9ILgfi013363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 9 Dec 2019 13:21:44 -0500
Date: Mon, 9 Dec 2019 10:21:41 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= <malisa.vucinic@inria.fr>
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
Message-ID: <20191209182141.GH13890@kduck.mit.edu>
References: <157250308434.32464.3300056120615958441.idtracker@ietfa.amsl.com> <2FDCD14C-AC9E-4577-9090-A43452B62020@inria.fr>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <2FDCD14C-AC9E-4577-9090-A43452B62020@inria.fr>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/EM6i65EgCkw2S6R1pt6FguEuvt4>
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: Mon, 09 Dec 2019 18:21:51 -0000

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