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

[Mohit Sethi <[e-mail]>]

Dear Tim,

Thanks for the detailed review and positive comments. We have now 
submitted an updated version which can be found here: 
https://tools.ietf.org/html/draft-ietf-lwig-crypto-sensors-05. The diff 
from the previous version can be found here: 
https://www.ietf.org/rfcdiff?url2=draft-ietf-lwig-crypto-sensors-05.

Please find our responses to your specific comments inline. Let us know 
if the modifications are not sufficient.

--Mohit
On 10/30/2017 12:03 AM, Tim Chown wrote:
> 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.
We have now added a summary of important security recommendations from 
our implementation experience in section 9.
>
> 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.
We have added new text here. "leap-of-faith or trust-on-first-use based 
pairing methods assume that the attacker is not present during the 
initial setup and are vulnerable to eavesdropping or man-in-the-middle 
(MitM) attacks."
>
> 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?
Christian had provided detailed feedback on privacy and identifiers. To 
address this, we have added new text in section 3 (Challenges), section 
4.1 (Provisioning) and section 8.1 (Feasibility).
>
> 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.
There was missing text here. We have now completed the sentence. "Our 
choice of a 8-bit platform may seem surprising since cheaper and more 
energy-efficient 32-bit platforms are available. However, our intention 
was to evaluate the performance of public-key cryptography on the 
smallest platforms available. It is reasonable to expect better 
performance results from 32-bit microcontrollers.
>
> On page 12, would a little more detail on RNG requirements, esp. for devices of
> this type, be worthwhile?
We have also added a pointer to RFC4086 that provides a detailed 
discussion on requirements and best practices for cryptographic-quality 
randomness.
>
> 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.
The IP address of the resource-directory was hardcoded. The location of 
the publish-subscriber broker was then discovered from the resource 
directory. I should also add that this was a prototype implementation on 
a small device. A real deployment would have used an actual domain name.
>
> On page 16, section 10 seems to have no content?  Or should sections 11 onwards
> be subsections of section 10?
Section 10, 11, 12, 13, 14 were related but somehow incorrectly placed. 
This was an xml formatting error on our part. We have now fixed 
section/subsection order.
>
> On page 17, at the end of section 11, should there also be some 'spin up' costs
> for the radio?
Added. "in general the power requirements necessary to turn the radio 
on/off and sending or receiving messages are far bigger than those 
needed to execute cryptographic operations."
>
> Best wishes,
> Tim
>
>