Re: [Lwip] Intdir early review of draft-ietf-lwig-crypto-sensors-04
Tim Chown <Tim.Chown@jisc.ac.uk> Mon, 05 February 2018 10:19 UTC
Return-Path: <tim.chown@jisc.ac.uk>
X-Original-To: lwip@ietfa.amsl.com
Delivered-To: lwip@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48AC4129C6E for <lwip@ietfa.amsl.com>; Mon, 5 Feb 2018 02:19:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.321
X-Spam-Level:
X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cABHV10Sk1dR for <lwip@ietfa.amsl.com>; Mon, 5 Feb 2018 02:19:29 -0800 (PST)
Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 916E5129BBF for <lwip@ietf.org>; Mon, 5 Feb 2018 02:19:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1517825967; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=0hxMa4ePwYhoX2X9OL2q2yEF9yjlAoenM/Eg9CDyn1I=; b=bIwnybaPfYhMZTn3gKr9IAH1yDd/YorUcPaYwgikB9XaoccWuF6UlhOISGSZLKKf9oXIE/gcBsgTdzX6K1xvWo2JVHvnl1o10q6luBR991Kd7nu3re/YJAW9OOAVjcA3FuGh73CKdqxzXGyUJzrhlqLnZ3asWVJeFZEVpAZQGU0=
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-am5eur03lp0112.outbound.protection.outlook.com [213.199.154.112]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-80--9ftUI9oOFauP9f8xGSs3g-1; Mon, 05 Feb 2018 10:19:23 +0000
Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB0712.eurprd07.prod.outlook.com (10.160.6.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.485.3; Mon, 5 Feb 2018 10:19:22 +0000
Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::84a9:709c:ffaa:41a7]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::84a9:709c:ffaa:41a7%13]) with mapi id 15.20.0485.009; Mon, 5 Feb 2018 10:19:22 +0000
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, 05 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
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3445.5.20)
x-originating-ip: [2001:a88:d510:1101:f9d7:22b5:aea7:c65a]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM3PR07MB0712; 7:sHmKMN+cGs4zaF5KWT5TxFH/knWOvqePzvBh59fOp+YQ9x7u+nYpkdZaEboo+6wSLBreQXaE0malwwJ2MJB5QeQrtRqtrasviy7oOPrzVyDmHGHZATvVzgie8OuCxWtmKZ/RVB0bmCPjFJrP8ZVQwTK52c4U1/xqCSpEDjwPq5I5EFkWRQyo1izfhnphWS50tX3zksXFVjS9Ybsl75aar9W5yxNv2wwyVMLy0mhea0IRB52/WCH0dTnIt/DX9/Py; 20:YixBlrXdIJ7DbEt9363udrQ+EP9qvoIExSTlDt/N7V0s95cfySugNTaQpLxTZNqpV2zprmtdg+ECU1JwPqaatdFEj/rNBM7Yy/zNYx8gfp86kG3FzJpJKTTQcMYOzrcdnhNlMPfd/is6iqDUK3EVe/EqjRoQHdY2HxFQc1oOG68=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: d64e5c57-a758-4c16-995d-08d56c81ecdc
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:AM3PR07MB0712;
x-ms-traffictypediagnostic: AM3PR07MB0712:
x-microsoft-antispam-prvs: <AM3PR07MB0712ABC3D202AA90201A579FD6FE0@AM3PR07MB0712.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(37575265505322)(192374486261705)(85827821059158);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(3231101)(2400082)(944501161)(6041288)(20161123564045)(20161123558120)(20161123562045)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(6072148)(201708071742011); SRVR:AM3PR07MB0712; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB0712;
x-forefront-prvs: 0574D4712B
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(396003)(39850400004)(366004)(376002)(39380400002)(51914003)(199004)(189003)(2900100001)(83716003)(305945005)(6246003)(57306001)(86362001)(229853002)(42882006)(105586002)(25786009)(2950100002)(7736002)(6506007)(53546011)(5250100002)(36756003)(50226002)(8936002)(786003)(102836004)(6116002)(316002)(8676002)(5660300001)(59450400001)(76176011)(2906002)(81166006)(81156014)(6346003)(186003)(14454004)(966005)(478600001)(74482002)(72206003)(106356001)(33656002)(3660700001)(82746002)(3280700002)(6436002)(54906003)(6512007)(68736007)(6306002)(53936002)(99286004)(6486002)(39060400002)(4326008)(97736004)(6916009); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB0712; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
x-microsoft-antispam-message-info: Q2/MxteKghsQgxLjO2hwSmfbB3g20byeG+1bdur94ItJDrIXlzuu4ze2pC1li8J6qAhI+19dQzqFrRKL6I63IA==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-ID: <F32E7EFB56A0ED4BAFE60B8837C69534@eurprd07.prod.outlook.com>
MIME-Version: 1.0
X-OriginatorOrg: jisc.ac.uk
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 > On 17 Jan 2018, at 07:56, Zhen Cao <zhencao.ietf@gmail.com> 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 > <mohit.m.sethi@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