Re: [secdir] [Roll] Secdir review of draft-ietf-roll-applicability-home-building-09 (resend)

peter van der Stok <stokcons@xs4all.nl> Tue, 07 April 2015 10:02 UTC

Return-Path: <stokcons@xs4all.nl>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C6241A1C02; Tue, 7 Apr 2015 03:02:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
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 SN41rcop2Lfc; Tue, 7 Apr 2015 03:02:53 -0700 (PDT)
Received: from lb3-smtp-cloud3.xs4all.net (lb3-smtp-cloud3.xs4all.net [194.109.24.30]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AD2D1A1BF6; Tue, 7 Apr 2015 03:02:52 -0700 (PDT)
Received: from roundcube.xs4all.nl ([194.109.20.207]) by smtp-cloud3.xs4all.net with ESMTP id Cy2m1q00W4U4Moq01y2mxz; Tue, 07 Apr 2015 12:02:50 +0200
Received: from a82-95-140-48.adsl.xs4all.nl ([82.95.140.48]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 07 Apr 2015 12:02:48 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Date: Tue, 07 Apr 2015 12:02:48 +0200
From: peter van der Stok <stokcons@xs4all.nl>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Organization: vanderstok consultancy
Mail-Reply-To: consultancy@vanderstok.org
In-Reply-To: <F189CF1A-B989-4326-9B1C-0856164687D7@nrl.navy.mil>
References: <F189CF1A-B989-4326-9B1C-0856164687D7@nrl.navy.mil>
Message-ID: <a552b9177a20932efc4c37de6f438432@xs4all.nl>
X-Sender: stokcons@xs4all.nl (KHqKdo85l6i8RT+HxnE6e+lTyi+pbyzT)
User-Agent: XS4ALL Webmail
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/g8oFdjeDqJ1aLGnV1d-4sM7LhqE>
Cc: draft-ietf-roll-applicability-home-building.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] [Roll] Secdir review of draft-ietf-roll-applicability-home-building-09 (resend)
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: consultancy@vanderstok.org
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Apr 2015 10:02:59 -0000

Hi Catherine,

thanks for pointing out sources of misunderstanding. Below some 
suggestions for new text.

Considering the values of section 4.1.8; I will look for an RFC that 
explains in more detail and cite that.
@Robert, can you recommend a RFC?


<old>
> New approaches to initial security deployment are being developed in
>  [I-D.kumar-dice-dtls-relay] and
>  [I-D.richardson-6tisch--security-6top]. They assume a partial
>  ordering of the nodes, such that unsecured nodes are added
>  sequentially with the restriction that a path between two secured
>  nodes exists which passes through secured nodes only.
</old>
<new>
New approaches to initial security deployment are being developed in
  [I-D.kumar-dice-dtls-relay] and
   [I-D.richardson-6tisch--security-6top]. In these drafts an already 
secured node assists in securing an unsecured 1-hop neighbour node.
Like an onion, a new layer of unsecured nodes is secured by a former 
layer of already secured nodes until all selected nodes are secured.
</new>

<old>
> In the home, nodes can be visually inspected by the home owner
>  and simple measures like pushing buttons simultaneously on joint and
>  joining devices is probably sufficient.
</old>
<new>
In the home, nodes can be visually inspected by the home owner
  and simple measures like pushing buttons simultaneously on joint and
  joining devices are probably sufficient to guarantee that keys are 
exchanged between the two nodes without major risks of security 
breaches.
</new>

<old>
> When nodes are lost, no additional security measures are needed, the
>  network remains secure as before by not allowing the addition of new
>  nodes.
</old>
<new>
  When nodes are lost, no additional security measures are needed, the
  network remains secure as before by considering the lost nodes as new 
nodes which have to pass through the join process.
</new>

Thanks for finding the NIT.

I hope the new text above clarifies the obscure points you found.

Greetings,

Peter

Catherine Meadows schreef op 2015-04-06 23:37:
> I had the draft authors’ email address wrong on my last message, so
> I am resending it.
> 
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG. These comments were written primarily for the benefit of the
> security area directors. Document editors and WG chairs should treat
> these comments just like any other last call comments.
> 
> This document gives recommendations for the use of RPL in home
> automation and building control,
> that typically provide support such things as climate and lighting
> control. I reviewed a much earlier
> version of this document, and I think this version is much improved in
> the way it scopes out the problem
> and handles the security implications. The Security Considerations
> section in particular is very
> thorough. There are a few improvements I would recommend, however:
> 
> Section 4.1.8 Security
> 
> You should give justifications for these choices of parameters as you
> give justifications for the
> other parameters described in this draft.
> 
> Section 7.1 Security considerations during initial deployment
> 
> New approaches to initial security deployment are being developed in
>  [I-D.kumar-dice-dtls-relay] and
>  [I-D.richardson-6tisch--security-6top]. They assume a partial
>  ordering of the nodes, such that unsecured nodes are added
>  sequentially with the restriction that a path between two secured
>  nodes exists which passes through secured nodes only.
> 
> I found this a little hard to understand. When does a node pass from
> being unsecured to secured? Or does an unsecured node remain
> unsecured? If there is
> a succinct way of saying this, it could go here. Since this is only
> describing new approaches that could potentially be applied, you would
> not
> want to go into a lot of detail.
> 
> In the home, nodes can be visually inspected by the home owner
>  and simple measures like pushing buttons simultaneously on joint and
>  joining devices is probably sufficient.
> 
> I think this definitely needs to be clarified! You need to say what is
> being accomplished by pushing the buttons (device pairing)?
> 
> 7.2
> 
> When nodes are lost, no additional security measures are needed, the
>  network remains secure as before by not allowing the addition of new
>  nodes.
> 
> I’m not sure what this means. Does it mean that if a node is lost,
> then it is treated as a “new node” if it reappears, and is not
> allowed
> to rejoin the network?
> 
> New nodes can be added by using the same protocols used for
>  initial deployment.
> 
> This came right after the sentence beginning “When nodes are lost”
> which said that new nodes are not added. That contradiction needs to
> be reconciled. I’m also not sure what “using the same protocol”
> means. Does it mean rerunning the protocol and rekeying all the nodes,
> or does
> it mean using the features that protocol has for adding nodes?
> 
> Nits:
> 
> Section 1.1
> 
> This applicability statement
>  recommends more light weight security solutions and specify the
>  conditions under which these solutions are appropriate.
> 
> Should be “specifies” instead of “specify”. I’m also not
> sure what is meant by “conditions under which these solutions are
> appropriate.” Do
> you mean light-weight as opposed to no security, or light-weight as
> opposed to heavy-weight. Or are you talking about conditions
> under which different light-weight solutions are appropriate? From
> reading the rest of the draft, I would assume the last is what you
> mean.
> 
> I consider this document ready with issues.
> 
>  Catherine Meadows
> Naval Research Laboratory
> Code 5543
> 4555 Overlook Ave., S.W.
> Washington DC, 20375
> phone: 202-767-3490
> fax: 202-404-7942
> email: catherine.meadows@nrl.navy.mil
> 
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll