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

[Zhen Cao <[e-mail]>]

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
>>
>>
>
>