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

[Tim Chown <[e-mail]>]

Hi,

I am happy with the update and the points being addressed.

Best wishes,
Tim 

> On 17 Jan 2018, at 07:56, Zhen Cao <[e-mail]> 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
> <[e-mail]> 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