[Roll] [roll] #176 (applicability-ami): Security items to consider for applicability-ami draft - IESG Evaluation-

"roll issue tracker" <trac+roll@trac.tools.ietf.org> Fri, 13 May 2016 11:25 UTC

Return-Path: <trac+roll@trac.tools.ietf.org>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id E711D12D146; Fri, 13 May 2016 04:25:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.896
X-Spam-Status: No, score=-7.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id x3Zhw8Q_Pdoo; Fri, 13 May 2016 04:25:03 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C76712D14C; Fri, 13 May 2016 04:25:03 -0700 (PDT)
Received: from localhost ([::1]:40449 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from <trac+roll@trac.tools.ietf.org>) id 1b1BDK-0000nU-Io; Fri, 13 May 2016 04:25:02 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "roll issue tracker" <trac+roll@trac.tools.ietf.org>
X-Trac-Version: 0.12.5
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.5, by Edgewall Software
To: draft-ietf-roll-applicability-ami@ietf.org, mariainesrobles@gmail.com
X-Trac-Project: roll
Date: Fri, 13 May 2016 11:25:02 -0000
X-URL: https://tools.ietf.org/wg/roll/
X-Trac-Ticket-URL: https://tools.ietf.org/wg/roll/trac/ticket/176
Message-ID: <068.f82ce53591c9bd896c9f7c9c9ddf7e60@trac.tools.ietf.org>
X-Trac-Ticket-ID: 176
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: draft-ietf-roll-applicability-ami@ietf.org, mariainesrobles@gmail.com, roll@ietf.org
X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: draft-ietf-roll-applicability-ami@ietf.org
Resent-Message-Id: <20160513112503.2C76712D14C@ietfa.amsl.com>
Resent-Date: Fri, 13 May 2016 04:25:03 -0700 (PDT)
Resent-From: trac+roll@trac.tools.ietf.org
Archived-At: <http://mailarchive.ietf.org/arch/msg/roll/tvdU4s3ikVFDyCQYDZLbQmp4e4U>
Cc: roll@ietf.org
Subject: [Roll] [roll] #176 (applicability-ami): Security items to consider for applicability-ami draft - IESG Evaluation-
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.17
Reply-To: roll@ietf.org
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 May 2016 11:25:05 -0000

#176: Security items to consider for applicability-ami draft - IESG Evaluation-

 I have two things I'd like to chat about, given that these
 applicability documents are where the roll WG has iirc
 said it'd address security and privacy issues with RPL:

 (1) 7.1.7: Don't you need to turn that "may not need"
 around and say that AMI deployments of RPL REQUIRE
 implementation (and maybe use) of link layer and higher
 layer security features? (You almost say that in 9.3 I
 think, so it'd maybe be good to be crystal clear.

 (2) Why are there no privacy considerations? I think this
 document needs that. For example, an AMI mesh based purely
 on link layer security could be a total privacy nightmare.
 And part of that is down to RPL - if I can cause lots of
 folks' traffic to be sent to me, that is RPL's issue.
 That I can then see the application layer content is not
 RPL's fault, but is still relevant.  I think this section
 is important to include because the authors here are
 presumably the ones who know the application layer
 information. And the sensitive information might not only
 be readings, it could include packet size, if larger
 packets are caused by activity such as turning on heating,
 then larger packets indicate presence and smaller ones
 absence, depending on weather. I am also concerned that
 there may be privacy issues arising from the various
 identifiers in use here.  Did the WG consider these issues
 and their potential impact on how it is or is not safe to
 use RPL? (While the analysis might sound complex, I'd bet
 that not much new text would be needed, but who knows
 until the analysis has been done.)

 - 1.3: what's the 3rd bullet mean? It's worded very
 ambiguously. With s/(vs. non-storing)// it'd be clear.

 - section 3: "a potentially significant portion of which
 is taken up by protocol and encryption overhead" seems
 overstated to me - are there numbers to back that up?

 - 5.1, last sentence: why is it important to note that?
 explaining would be good

 - 7.2.3: I don't get what you're telling me here that
 assists in security or interop?

 - section 9: please provide references to back up the
 assertion that "many available security mechanisms are not
 practical for use in such networks" for some relevant
 security mechanisms. The problem is that such assertions
 are used to justify doing nothing at all so they ought not
 be blithely made.

 - 9.1: "are unique per device" etc is the only sensible
 thing and would be nice if always true, but that is often
 not the case - why state what's known to not be true? Or
 are you trying to say something else?

 - 9.2: "it is replaced" - again that's not true, only
 devices known to be compromised would be replaced, which
 is by no means all compromised devices

 - 9.3: "already existing" - you really should have a
 reference there.

 Reporter:                           |      Owner:  draft-ietf-roll-
  mariainesrobles@gmail.com          |  applicability-ami@ietf.org
     Type:  defect                   |     Status:  new
 Priority:  major                    |  Milestone:
Component:  applicability-ami        |    Version:
 Severity:  In WG Last Call          |   Keywords:

Ticket URL: <https://tools.ietf.org/wg/roll/trac/ticket/176>
roll <https://tools.ietf.org/wg/roll/>