Hi, I am happy with the update and the points being addressed.
Best wishes, Tim > On 17 Jan 2018, at 07:56, Zhen Cao <[email protected]> wrote: > > 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 > <[email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/lwip
