Re: [Lwip] [Non-DoD Source] Genart last call review of draft-ietf-lwig-crypto-sensors-05

"KELLY, MICHAEL B CTR USAF AFMC 412 TENG/ENI" <michael.kelly.49.ctr@us.af.mil> Tue, 13 February 2018 15:19 UTC

Return-Path: <prvs=1575562986=michael.kelly.49.ctr@us.af.mil>
X-Original-To: lwip@ietfa.amsl.com
Delivered-To: lwip@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7BE0127873; Tue, 13 Feb 2018 07:19:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.407
X-Spam-Level:
X-Spam-Status: No, score=-3.407 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RDNS_NONE=0.793, SPF_PASS=-0.001, URIBL_BLOCKED=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 AxkSEXaBSxTL; Tue, 13 Feb 2018 07:19:51 -0800 (PST)
Received: from SCOTT-MAIL4.AFNOC.AF.MIL (unknown [131.9.253.48]) (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 94C15126C2F; Tue, 13 Feb 2018 07:19:47 -0800 (PST)
Received: from us.af.mil (unknown [131.15.70.110]) by SCOTT-MAIL4.AFNOC.AF.MIL with smtp (TLS: TLSv1/SSLv3,256bits,DHE-RSA-AES256-SHA) id 7641_e2a7_033be648_f76d_44c2_9520_f802c1f2842a; Tue, 13 Feb 2018 15:19:45 +0000
Received: from ([131.15.68.156]) by 52tdkp-mr-004.us.af.mil with ESMTP with TLS id 91Z0FN1.233521675; Tue, 13 Feb 2018 08:05:14 -0700
Received: from 52ZHTX-D02-05E.AREA52.AFNOAPPS.USAF.MIL (131.27.55.10) by 52TDKP-D02-02A.area52.afnoapps.usaf.mil (131.15.68.156) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 13 Feb 2018 08:19:31 -0700
Received: from 52ZHTX-D05-05E.AREA52.AFNOAPPS.USAF.MIL ([169.254.5.239]) by 52ZHTX-D02-05E.area52.afnoapps.usaf.mil ([169.254.5.195]) with mapi id 14.03.0361.001; Tue, 13 Feb 2018 10:19:29 -0500
From: "KELLY, MICHAEL B CTR USAF AFMC 412 TENG/ENI" <michael.kelly.49.ctr@us.af.mil>
To: Dan Romascanu <dromasca@gmail.com>, "gen-art@ietf.org" <gen-art@ietf.org>
CC: "lwip@ietf.org" <lwip@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "draft-ietf-lwig-crypto-sensors.all@ietf.org" <draft-ietf-lwig-crypto-sensors.all@ietf.org>
Thread-Topic: [Non-DoD Source] Genart last call review of draft-ietf-lwig-crypto-sensors-05
Thread-Index: AQHTpLfDXb4LsWmuh0em2vVpll1VxaOicjaA
Date: Tue, 13 Feb 2018 15:19:29 +0000
Message-ID: <C100D0AB51422F48B5655B0FD58BB20402BD0B3A@52ZHTX-D05-05E.area52.afnoapps.usaf.mil>
References: <151851864376.22238.17813481758804477460@ietfa.amsl.com>
In-Reply-To: <151851864376.22238.17813481758804477460@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-dset: 0-NNZN-0
x-originating-ip: [131.27.49.6]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/lwip/zWmIktrKb3LKKMWB9Y-CVzTuKEg>
Subject: Re: [Lwip] [Non-DoD Source] Genart last call review of draft-ietf-lwig-crypto-sensors-05
X-BeenThere: lwip@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Lightweight IP stack <lwip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lwip>, <mailto:lwip-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lwip/>
List-Post: <mailto:lwip@ietf.org>
List-Help: <mailto:lwip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lwip>, <mailto:lwip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Feb 2018 15:19:59 -0000

Hello All,

I was invited into this list because I had some questions.  I am not able to contribute anything so would someone be so kind as to remove me from this list.  My email is michael.kelly.49.ctr@us.af.mil

Thank you for your time,
M Bryan Kelly
JT3/ATAC Contractor
412 TENG/ENIE CANIS Software
661-277-7852
DSN 527-7852
Blg 1600 Block 500
300 E. Yeager Blvd
Edwards AFB, 93524

-----Original Message-----
From: ietf [mailto:ietf-bounces@ietf.org] On Behalf Of Dan Romascanu
Sent: Tuesday, February 13, 2018 2:44 AM
To: gen-art@ietf.org
Cc: lwip@ietf.org; dromasca@gmail.com; ietf@ietf.org; draft-ietf-lwig-crypto-sensors.all@ietf.org
Subject: [Non-DoD Source] Genart last call review of draft-ietf-lwig-crypto-sensors-05

Reviewer: Dan Romascanu
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair.  Please treat these comments just like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-lwig-crypto-sensors-05
Reviewer: Dan Romascanu
Review Date: 2018-02-13
IETF LC End Date: 2018-02-19
IESG Telechat date: 2018-02-22

Summary:

This is a well-written clear informational memo, documenting methods to secure networks built of resource-constrained devices. It describes a deployment model based on exchanges of signed objects, and documents available cryptographic libraries that may be suited to the targets. The conclusions include analysis of trade-offs and recommendations for future development and deployments.

The document is READY from Gen-ART perspective. There are a couple of non-blocking issues that I would be glad to have them clarified before approval. I have also pointed to a couple of nits.

Major issues:

Minor issues:

1. In Section 7:

'The location of the resource directory was configured into
   the smart object sensor by hardcoding the IP address'

Is this reasonable? I understand that the goal of the exercise was to demonstrate that it is possible to implement the entire architecture with public-key cryptography on an 8-bit micro-controller, but hard-coding the IP address seems to be below the threshold of a functional system. IMO there is a need to be able for the sensor to acquire this address (DHCP stack, or a simple UI to stream in one address, etc.)

2. In section 8.1 - I would expect some discussion about the extra-power needed to run the cryptography. There is a statement about these being less than device wake-up and sending messages, but some quantitative evaluation (in
percentage) of the impact would be useful, taking into account that battery capacity is one of the most important constrained resources.

Nits/editorial comments:

1. The document uses the alternate term of 'small devices' for 'resource-constraint devices'. I view this as kind of an inaccurate verbal automatism in the world of IoT, as 'small' is a relative term, resource-constrained devices are not necessarily small (like in reduced physical footprint), and small devices can be rich in resources. I would suggest to either avoid the term, or explain what it means in the context (e.g.
''Smart objects', 'small devices' and 'resource-constrained devices are used interchangeably in this document and mean ...')

2. Please expand ECDSA at first occurrence