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:
We have now added a summary of important security recommendations from our implementation experience in section 9.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 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."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.
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 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?
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 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.
We have also added a pointer to RFC4086 that provides a detailed discussion on requirements and best practices for cryptographic-quality randomness.On page 12, would a little more detail on RNG requirements, esp. for devices of this type, be worthwhile?
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, 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.
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 16, section 10 seems to have no content? Or should sections 11 onwards be subsections of section 10?
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."On page 17, at the end of section 11, should there also be some 'spin up' costs for the radio?
Best wishes, Tim
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Lwip mailing list [email protected] https://www.ietf.org/mailman/listinfo/lwip
