From: Tim Chown <Tim.Chown@jisc.ac.uk>
To: Zhen Cao <zhencao.ietf@gmail.com>
CC: Mohit Sethi <mohit.m.sethi@ericsson.com>, "lwip@ietf.org" <lwip@ietf.org>, 
 "draft-ietf-lwig-crypto-sensors.all@ietf.org"
 <draft-ietf-lwig-crypto-sensors.all@ietf.org>
Thread-Topic: Intdir early review of draft-ietf-lwig-crypto-sensors-04
Thread-Index: AQHTj2it4xM/MZAf+0azQ6dKEhHCFaOVtsGA
Date: Mon, 5 Feb 2018 10:19:22 +0000
Message-ID: <801A8CCD-81C5-4438-908C-C909569C02EA@jisc.ac.uk>
References: <150931458233.3515.10214190547457562395@ietfa.amsl.com>
 <e5c315d9-2326-7e64-edc0-ba016706ab6c@ericsson.com>
 <CAFxP68zH6kgk3wq6-UN3kjd8yWj8naFuHZCba0frQPjz6uhpTw@mail.gmail.com>
In-Reply-To: <CAFxP68zH6kgk3wq6-UN3kjd8yWj8naFuHZCba0frQPjz6uhpTw@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-ID: <F32E7EFB56A0ED4BAFE60B8837C69534@eurprd07.prod.outlook.com>
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: d64e5c57-a758-4c16-995d-08d56c81ecdc
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Feb 2018 10:19:22.2785 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB0712
X-MC-Unique: -9ftUI9oOFauP9f8xGSs3g-1
Content-Type: text/plain; charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/lwip/6IM4RcKitSXq04R18V5D5APdMwM>
Subject: Re: [Lwip] Intdir early review of draft-ietf-lwig-crypto-sensors-04
X-BeenThere: lwip@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Lightweight IP stack <lwip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lwip>,
 <mailto:lwip-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lwip/>
List-Post: <mailto:lwip@ietf.org>
List-Help: <mailto:lwip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lwip>,
 <mailto:lwip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Feb 2018 10:19:34 -0000

Hi,

I am happy with the update and the points being addressed.

Best wishes,
Tim=20

> On 17 Jan 2018, at 07:56, Zhen Cao <zhencao.ietf@gmail.com> wrote:
>=20
> Hi Tim,
>=20
> Thank you again for reviewing this document, and a very happy new year
> of 2018 :)
>=20
> 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.
>=20
> Many thanks and regards,
> Zhen
>=20
> On Tue, Dec 26, 2017 at 12:49 AM, Mohit Sethi
> <mohit.m.sethi@ericsson.com> wrote:
>> Dear Tim,
>>=20
>> Thanks for the detailed review and positive comments. We have now submit=
ted
>> 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=3Ddraft-ietf-lwig-crypto-sensors-05.
>>=20
>> Please find our responses to your specific comments inline. Let us know =
if
>> the modifications are not sufficient.
>>=20
>> --Mohit
>>=20
>> On 10/30/2017 12:03 AM, Tim Chown wrote:
>>>=20
>>> Reviewer: Tim Chown
>>> Review result: Ready
>>>=20
>>> Hi,
>>>=20
>>> 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.
>>>=20
>>> 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.
>>>=20
>>> General comments:
>>>=20
>>> 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.
>>>=20
>>> It may be worth considering teasing apart the evaluation and the
>>> architectural
>>> aspects of the document; these are somewhat interwoven as currently
>>> written.
>>>=20
>>> Related, there are some rather nice recommendations made throughout the
>>> document; these could perhaps be summarised either at the start or perh=
aps
>>> better the close of the document, e.g. on page 4 regarding selecting th=
e
>>> 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.
>>=20
>> We have now added a summary of important security recommendations from o=
ur
>> implementation experience in section 9.
>>>=20
>>>=20
>>> Comments by page:
>>>=20
>>> 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 h=
int
>>> here, or just adding "as discussed on page 6 or in section x.y" might b=
e
>>> nice.
>>>=20
>>> Also on page 5, I'd be interested in seeing some brief text added on th=
e
>>> "remaining vulnerabilities" that are mentioned near the foot of the pag=
e.
>>=20
>> 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 initi=
al
>> setup and are vulnerable to eavesdropping or man-in-the-middle (MitM)
>> attacks."
>>>=20
>>>=20
>>> On page 6, is it worth adding a little text on privacy somewhere?  We'v=
e
>>> been
>>> doing some work through Christian Huitema and Daniel Kaiser on anonymou=
s
>>> device
>>> pairing in the DNSSD WG, and a similar requirement might be desirable i=
n
>>> some
>>> scenarios here?
>>=20
>> 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).
>>>=20
>>>=20
>>> 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.
>>=20
>> There was missing text here. We have now completed the sentence. "Our ch=
oice
>> 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 resul=
ts
>> from 32-bit microcontrollers.
>>>=20
>>>=20
>>> On page 12, would a little more detail on RNG requirements, esp. for
>>> devices of
>>> this type, be worthwhile?
>>=20
>> We have also added a pointer to RFC4086 that provides a detailed discuss=
ion
>> on requirements and best practices for cryptographic-quality randomness.
>>>=20
>>>=20
>>> On page 16, you're hardcoding the IP address?  Is it not possible to us=
e
>>> RD?
>>> We've been comparing that and looking at interoperability with classic
>>> DNSSD in
>>> the DNSSD WG.
>>=20
>> The IP address of the resource-directory was hardcoded. The location of =
the
>> publish-subscriber broker was then discovered from the resource director=
y. I
>> should also add that this was a prototype implementation on a small devi=
ce.
>> A real deployment would have used an actual domain name.
>>>=20
>>>=20
>>> On page 16, section 10 seems to have no content?  Or should sections 11
>>> onwards
>>> be subsections of section 10?
>>=20
>> 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.
>>>=20
>>>=20
>>> On page 17, at the end of section 11, should there also be some 'spin u=
p'
>>> costs
>>> for the radio?
>>=20
>> 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."
>>>=20
>>>=20
>>> Best wishes,
>>> Tim