Skip to main content

Last Call Review of draft-ietf-lwig-crypto-sensors-05

Request Review of draft-ietf-lwig-crypto-sensors
Requested revision No specific revision (document currently at 06)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2018-02-19
Requested 2018-02-05
Authors Mohit Sethi , Jari Arkko , Ari Keränen , Heidi-Maria Back
I-D last updated 2018-02-13
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 Dan Romascanu
State Completed
Request Last Call review on draft-ietf-lwig-crypto-sensors by General Area Review Team (Gen-ART) Assigned
Reviewed revision 05 (document currently at 06)
Result Ready w/issues
Completed 2018-02-13
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


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


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