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

Jens Toftgaard Petersen <> Thu, 15 December 2016 22:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 362EE1294D1; Thu, 15 Dec 2016 14:05:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id l-hTHgWmTcmG; Thu, 15 Dec 2016 14:05:09 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0FC66129552; Thu, 15 Dec 2016 14:05:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-rtx-dk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/vU/3BqUZdCWwyPLQEsW4pdMgDQjD1CGgsCqrpmc3D4=; b=keSLD7hGusLeBFtkS8dR0uJsIIVDm3RJUVqkUbhJlikpiCoxXwJrEkRUO5w3zq4Y6fSWf4ATa5dexiHfkedLhWuGRdnS7wktPjPhEGuYNsDGM2lmLik1/2vKQDj/S3xYziEJ29hdST1fjwT+sGCnyHCLm3LiKtZrs1C44NzBpjU=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.771.8; Thu, 15 Dec 2016 22:05:05 +0000
Received: from ([]) by ([]) with mapi id 15.01.0771.014; Thu, 15 Dec 2016 22:05:05 +0000
From: Jens Toftgaard Petersen <>
To: Simon Josefsson <>, "" <>, "" <>, "" <>
Thread-Topic: Review of draft-ietf-6lo-dect-ule-08
Thread-Index: AQHSTLxu1C7wFwQzMUGYIZ37fEFByqEJKQ8w
Date: Thu, 15 Dec 2016 22:05:04 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: da-DK, en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-office365-filtering-correlation-id: 74a78b5c-4b65-4beb-0cb9-08d425366cdc
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:AM5PR0401MB2594;
x-microsoft-exchange-diagnostics: 1; AM5PR0401MB2594; 7:0IFX7RX25V2WEB1S3qVjxj7P6V5DY/5kHpAhG42F9MbwUO8L1Hg96DbO5nx2zOAyqdUuIUENJHSCeH95cfeBbIpqKnvFN4As5wRz88R12OwtubCRNu6EFjvBSLp+FbjvuTfkV+Lhw3mnHvcHohOXXNn4b9vJCdxheGoOEyy0NXFYTNrsMmPaR0CaIULW20nCZENjFzObVKhuxvsc/hc3As04VyAbCRWRQkDmBUVBsIKNHMHtZJS5ktTPXDE21wqxYJ7VtwVsj3xeNMgt4KJu/DUX9hkuRAvRefUrJiaIp/PnL7w9dsvEjFWar+hx+pVfv2vJKcGLNyx2VN5xRpB3iB80SvJSVAgXG172ewEhvjLl/4xJsnQZkte9T9jSdid0dwbUMM3KAKpxCcJEHUBavKzht/hkPyxhryAlfYhTmjMTw11eGIexcAY2k0YCd3KFAhv13zpWLMGv8tLRQQvR1w==
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(192374486261705);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123560025)(20161123564025)(20161123555025)(20161123562025)(6072148)(6047074); SRVR:AM5PR0401MB2594; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0401MB2594;
x-forefront-prvs: 0157DEB61B
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39840400002)(39850400002)(39410400002)(39450400003)(199003)(66654002)(189002)(13464003)(38730400001)(77096006)(5660300001)(76576001)(106356001)(229853002)(76176999)(74482002)(122556002)(68736007)(66066001)(2501003)(6506006)(25786008)(50986999)(2950100002)(54356999)(106116001)(92566002)(101416001)(9686002)(81166006)(33656002)(81156014)(8936002)(7736002)(3660700001)(2900100001)(7696004)(2906002)(8676002)(74316002)(3846002)(102836003)(6436002)(5001770100001)(305945005)(2201001)(6116002)(86362001)(189998001)(107886002)(97736004)(3280700002)(105586002)(230783001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0401MB2594;; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Dec 2016 22:05:05.0074 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 9a968248-e61d-46fd-b8d1-5c62247712e5
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0401MB2594
Archived-At: <>
Subject: Re: [secdir] Review of draft-ietf-6lo-dect-ule-08
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 15 Dec 2016 22:05:11 -0000

Hi Simon,

Many thanks for your review. See my comments and answers inline below.

Best regards,

-----Original Message-----
From: Simon Josefsson [] 
Sent: 2. december 2016 17:52
Subject: Review of draft-ietf-6lo-dect-ule-08

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

[Jens]: I have added more information and recommendation in new revision -09

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)'.

[Jens]: I prefer to keep the title, but change the abstract and introduction as you suggested.