[secdir] Review of draft-ietf-6lo-dect-ule-08

Simon Josefsson <simon@josefsson.org> Fri, 02 December 2016 16:52 UTC

Return-Path: <simon@josefsson.org>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 729E61295E7; Fri, 2 Dec 2016 08:52:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 zJDu_CvK7IfI; Fri, 2 Dec 2016 08:52:01 -0800 (PST)
Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 6CDE2129454; Fri, 2 Dec 2016 08:52:01 -0800 (PST)
Received: from latte.josefsson.org ([155.4.17.2]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id uB2GpvAH023945 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 2 Dec 2016 17:51:58 +0100
X-Hashcash: 1:22:161202:iesg@ietf.org::3NUdoAUKf0hCSNr5:LFX5
X-Hashcash: 1:22:161202:secdir@ietf.org::LOkyyf61HcBZ2B10:HN4j
X-Hashcash: 1:22:161202:draft-ietf-6lo-dect-ule.all@ietf.org::1MtOQn9hw0b2ND4L:7/XE
From: Simon Josefsson <simon@josefsson.org>
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-6lo-dect-ule.all@ietf.org
OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt
Date: Fri, 02 Dec 2016 17:51:55 +0100
Message-ID: <87polal1ec.fsf@latte.josefsson.org>
User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
X-Virus-Scanned: clamav-milter 0.99.2 at duva.sjd.se
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/3E1g-Ccfeq6U0fWcxc5kQ3FL_3w>
Subject: [secdir] Review of draft-ietf-6lo-dect-ule-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 02 Dec 2016 16:52:08 -0000

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.

The draft describes how to transmit IPv6 packets over DECT ULE using
6LoWPAN.  The document contains a good introduction to DECT, which is
particulary helpful to the IETF community.  The security consideration
already mentions the privacy concern related to link-level MAC
addresses, which is something that would otherwise would be easy to
criticize.  The document uses acronyms which makes it difficult to read
but the document strikes me as well written and well thought out anyway.

I believe the document is Ready with Nits.

Major nits:

1) Security Considerations.  I believe the document should state that
IPv6 traffic transmitted over DECT ULE should be protected using normal
IETF protocols (e.g., IPSEC or TLS) when there is a need for security.
The text says DECT ULE is secured using AES-CCM keyed from the DECT ULE
pairing, implying that this offers some security.  The document does not
explain (or inspire confidence) that the pairing process of DECT ULE has
sufficient entropy as input to provide good link-level security, nor
that it is based on any well established protocol.  A word or two about
this would be informative, but not really required.  The process may be
completely secure, but it may also not be.  I don't recall any link
layer security protocol that haven't had a significant security problem
in the past.  Regardless, I believe it is warranted to safeguard readers
that they should not consider DECT ULE transport a secure transport for
protecting data at the transport and/or application level.  Implementers
need to employ transport and/or application-level security like
IPSEC/TLS/CMS/OpenPGP as well.  To address my concern, I suggest to add
the following after the third paragraph:

   While DECT ULE offer some link-layer security properties, the
   transport of data over DECT ULE may require additional transport
   protocol, or application protocol, security guarantees.  When there
   is a need, the use of IPSEC [RFC XXXX], TLS [RFC YYYY], CMS [RFC
   ZZZZ], OpenPGP [RFC QQQQ] or similar security protocols, are
   recommended.

Minor nits:

A) Spell out DECT in the abstract and title.  In the introduction
section, change 'DECT (Digital Enhanced Cordless Telecommunications)'
into 'Digital Enhanced Cordless Telecommunications (DECT)'.

Cheers,
/Simon