Hi Tim, Thank you again for reviewing this document, and a very happy new year of 2018 :)
Could you help review the update according to Mohit's update and see if you have further concerns? so that as shepherd I can see if I can move it further. Many thanks and regards, Zhen On Tue, Dec 26, 2017 at 12:49 AM, Mohit Sethi <mohit.m.se...@ericsson.com> wrote: > 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 >> >> > > _______________________________________________ Lwip mailing list Lwip@ietf.org https://www.ietf.org/mailman/listinfo/lwip
