Skip to main content

Early Review of draft-ietf-lwig-crypto-sensors-04

Request Review of draft-ietf-lwig-crypto-sensors
Requested revision 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
Authors Mohit Sethi , Jari Arkko , Ari Keränen , Heidi-Maria Back
I-D last updated 2017-10-29
Completed reviews Secdir Early review of -04 by Christian Huitema (diff)
Intdir Early review of -04 by Tim Chown (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)
Assignment Reviewer Tim Chown
State Completed
Request Early review on draft-ietf-lwig-crypto-sensors by Internet Area Directorate Assigned
Reviewed revision 04 (document currently at 06)
Result Ready
Completed 2017-10-29

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

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,