[6tisch] comments on draft-piro-6tisch-security-issues

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 14 May 2014 00:42 UTC

Return-Path: <mcr@sandelman.ca>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2CE81A00DC; Tue, 13 May 2014 17:42:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.532
X-Spam-Level:
X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_MIME_NO_TEXT=0.01, T_TVD_MIME_NO_HEADERS=0.01] 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 XDxQWyCq0lgu; Tue, 13 May 2014 17:41:58 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.252.184]) by ietfa.amsl.com (Postfix) with ESMTP id 40B251A00DB; Tue, 13 May 2014 17:41:58 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5C63E2002B; Tue, 13 May 2014 20:43:47 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 989E563B1C; Tue, 13 May 2014 20:41:50 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 84A9D63B17; Tue, 13 May 2014 20:41:50 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: draft-piro-6tisch-security-issues@tools.ietf.org
X-Attribution: mcr
X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Tue, 13 May 2014 20:41:50 -0400
Message-ID: <11990.1400028110@sandelman.ca>
Sender: mcr@sandelman.ca
Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch/aQSmKZYrC98aFAGrAFpFo4fiIj8
Cc: 6tisch@ietf.org, 6tisch-security@ietf.org
Subject: [6tisch] comments on draft-piro-6tisch-security-issues
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Wed, 14 May 2014 00:42:03 -0000

I found this document to be a useful overview of 802.15.4 physical/layer-2
security options.

I don't agree with your title! I don't see how this is a "security
framework". It is something much more useful and important.
The analysis in section 3 is very useful.

I am not sure that I understand section 4.

Thank you for giving the network definitions in section 5.0.
It would be worth making it clear in the definition of fully secure that all
broadcasts are encrypted, including the beacon.

The _Hybrid Secured network_ is likely the most common, and not because nodes
are not capable of encryption, but because they don't have the key (yet!!).

The Setting-up Phase seems to assume a provisioning process to distribute
this MasterKey.  It could be that the MasterKey comes from something like
1x/PANA?

I like that the document uses 6top API to set things up.
My understanding is that 6.3 describes a way to get fresh per-cluster keying.
It appears that this is done over a layer-2 protocol.  Why not MLE?


Some editorial nits:
in section 6.1.1 the word "exploit"(ed) is technically correct, but perhaps
   an unfortunate choice for many non-english/french speakers.
   "exploiter" en francois is perhaps best translated as "leverage"
   In IT circles, many understand an "exploit" to be a security flaw..

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-