[Lwip] Intdir early review of draft-ietf-lwig-crypto-sensors-04

[Tim Chown <[e-mail]>]

Reviewer: Tim Chown
Review result: Ready

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