Early Review of draft-ietf-lwig-crypto-sensors-04
review-ietf-lwig-crypto-sensors-04-intdir-early-chown-2017-10-29-00

Request Review of draft-ietf-lwig-crypto-sensors
Requested rev. no specific revision (document currently at 06)
Type Early Review
Team Internet Area Directorate (intdir)
Deadline 2017-10-18
Requested 2017-09-29
Requested by Suresh Krishnan
Other Reviews Secdir Early review of -04 by Christian Huitema (diff)
Iotdir Early review of -04 by Samita Chakrabarti (diff)
Opsdir Telechat review of -05 by √Čric Vyncke (diff)
Rtgdir Telechat review of -05 by Emmanuel Baccelli (diff)
Genart Last Call review of -05 by Dan Romascanu (diff)
Secdir Last Call review of -05 by Christian Huitema (diff)
Review State Completed
Reviewer Tim Chown
Review review-ietf-lwig-crypto-sensors-04-intdir-early-chown-2017-10-29
Posted at https://mailarchive.ietf.org/arch/msg/int-dir/3gZFBnS1vELDhLkKj7ZmxTjyb1E
Reviewed rev. 04 (document currently at 06)
Review result Ready
Draft last updated 2017-10-29
Review completed: 2017-10-29

Review
review-ietf-lwig-crypto-sensors-04-intdir-early-chown-2017-10-29

Hi,

This Informational draft describes the challenges in securing resource-constrained smart object / IoT devices, documenting the associated tradeoffs, and discussing the availability of appropriate cryptographic libraries for such devices.

I have reviewed this document, and overall find it generally ready for publication, though I have some minor nits / comments for consideration below; these are just suggested changes / improvements, and I would not object strongly if all were ignored.

General comments:

The document is very easy and enjoyable to read, and the quality of the writing is very good.  The authors have clear expertise in the field.

It may be worth considering teasing apart the evaluation and the architectural aspects of the document; these are somewhat interwoven as currently written.

Related, there are some rather nice recommendations made throughout the document; these could perhaps be summarised either at the start or perhaps better the close of the document, e.g. on page 4 regarding selecting the hardware after determining the security requirements for a device, and not necessarily simply picking the most lightweight algorithm, or on page 7 regarding appropriate layers for tasks, or on page 9 regarding elliptic curve vs RSA, or on page 11 on real deployments using 32-bit microcontrollers, or the recommendation to the IETF community on page 14, or on planning for firmware updates on page 16, etc.

Comments by page:

On page 5, in the first paragraph on provisioning, there is no hint of any bootstrap process for identities; this follows later on page 6, but a hint here, or just adding "as discussed on page 6 or in section x.y" might be nice.

Also on page 5, I'd be interested in seeing some brief text added on the "remaining vulnerabilities" that are mentioned near the foot of the page.

On page 6, is it worth adding a little text on privacy somewhere?  We've been doing some work through Christian Huitema and Daniel Kaiser on anonymous device pairing in the DNSSD WG, and a similar requirement might be desirable in some scenarios here?

On page 7, having said earlier you should pick the hardware after determining requirements, you then decide to pick an Arduino platform and see what you can manage to run on it. I fully understand why (and I'd be equally curious), but you should probably clarify the "conflict" further.

On page 12, would a little more detail on RNG requirements, esp. for devices of this type, be worthwhile?

On page 16, you're hardcoding the IP address?  Is it not possible to use RD?  We've been comparing that and looking at interoperability with classic DNSSD in the DNSSD WG.

On page 16, section 10 seems to have no content?  Or should sections 11 onwards be subsections of section 10?

On page 17, at the end of section 11, should there also be some 'spin up' costs for the radio?

Best wishes,
Tim