[RTG-DIR] RtgDir review of draft-ietf-lwig-crypto-sensors-05.txt

[Emmanuel Baccelli <[e-mail]>]

Hello,

I have been selected as the Routing Directorate reviewer for this draft.
The Routing Directorate seeks to review all routing or routing-related
drafts as they pass through IETF last call and IESG review, and sometimes
on special request. The purpose of the review is to provide assistance to
the Routing ADs. For more information about the Routing Directorate, please
see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it
would be helpful if you could consider them along with any other IETF Last
Call comments that you receive, and strive to resolve them through
discussion or by updating the draft.

Document: draft-ietf-lwig-crypto-sensors-05.txt
Reviewer: Emmanuel Baccelli
Review Date: 20/02/2018
Intended Status: Informational

Summary:

This document is basically ready for publication, but has nits that should
be considered prior to publication.


Comments:

The draft's content are solid and relevant, the readability is good.
I have a few suggestions on how to further improve readability.


Major Issues:

No major issues found.


Minor Issues:

In section 8.3, concerning network layer security, it would be more
complete to also mention specific routing security aspects, e.g. cases
where multi-hop is needed in a LoWPAN, and mechanisms (such as topology
authentication) should be used to mitigate sinkhole attacks etc.

In the end summary, maybe it would also make sense to add something like:
"If push comes to shove, strong security is also possible on 8-bit and
16-bit".
I think it is important to send the message that even some "legacy" IoT
hardware could be made secure.


Nits:

# Section 3: the "network configuration" bullet point is somewhat unclear,
hinting at different issues. Would it not make sense to split it in 2
different bullet points?

# Section 4.1: it would be clearer if the main principles used for
provisionning are gathered and stated upfront in this section. I mean a
short list like
"only identities are provisionned",
"identities are self-securing".

# Section 4.1 in the part on group identity: at first sight it is not
straightforward what is n and what is m, and why they might be differ. Some
explicit mention would be useful.

# Section 4.1 in the part on group identity: does the model require each
device to be provided with the identities of all the other devices in the
group at commissionning time?
It is unclear in the text, an explicit mention would be useful here too.

# Section 5: it is somewhat awkward to find an OS within a list of crypto
libraries.
However, I agree it is important to point to available operating systems in
this space.
I suggest a separate paragraph on operating systems and citing a survey
such as:
O. Hahm et al. "Operating Systems for Low-end Devices in the Internet of
Things: a Survey." IEEE Internet of Things Journal 3.5 (2016): 720-734.

As a side note, it would be great to have an equivalent survey to point to
for
available light-weight crypto libraries...

# Section 6: in the beginning of the section, it is not clear that the
measurements are on Arduino Uno (right?).
I suggest stating this explicitly.

# Section 6: "The Arduino board only provides ... the random() function
call."
I think this sentence is somewhat misleading.
The main point here is what there is (or what there isn't) behind this
function call.
I suggest rephrasing the bullet point with something like:
"some boards (e.g. Arduino Uno) do not provide a hardware random number
generator.
On such boards, obtaining crypto-quality randomness is an issue."


# Spotted typos:

in Section 6 "results for for all the 128"
in Section 7 "enough power to be stay on"