[secdir] Secdir early review of draft-ietf-lwig-crypto-sensors-04

Christian Huitema <huitema@huitema.net> Sun, 15 October 2017 16:38 UTC

Return-Path: <huitema@huitema.net>
X-Original-To: secdir@ietf.org
Delivered-To: secdir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 30A4E1331D2; Sun, 15 Oct 2017 09:38:17 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Christian Huitema <huitema@huitema.net>
To: secdir@ietf.org
Cc: lwip@ietf.org, ietf@ietf.org, draft-ietf-lwig-crypto-sensors.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.63.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150808549717.12118.1993584722866227993@ietfa.amsl.com>
Date: Sun, 15 Oct 2017 09:38:17 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/Ln5PbxMlrBeQqHkKFeS9v3OylDY>
Subject: [secdir] Secdir early review of draft-ietf-lwig-crypto-sensors-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 15 Oct 2017 16:38:17 -0000

Reviewer: Christian Huitema
Review result: Has Nits

This is an early review of draft-ietf-lwig-crypto-sensors-04 on behalf of the Security Directorate. 

The document is almost ready, but would benefit from a bit more further work.

This draft examines a series of risks and challenges posed by securing small devices,
proposes solutions for provisioning, and an architecture for securing the devices.
The implementation experience section (section 8) provides measurements for the
memory and CPU costs of various cryptographic operations using the Arduino
platform. It will be good to see these results published and become a useful
reference in further debates. In fact, I like this document a lot. My only
concern is that it misses an opportunity to discuss identifiers and privacy.
 
I like the discussion of platform constraints in section 3, and the statement that "at
the end of the day, if strong cryptographic security is needed, the implementations 
have to support that." I think it is an important message, and it it might be
good to reinfore it with examples. For example, we do ship medecine in child-proof
containers. It would be cheaper to use ordinary containers, but we pay the cost
because as a society we want to mitigate the risk of children mistaking pills for candy.
Similarly, it is cheaper to build devices with no security, but we may want society
to mandate that risks should be mitigated.

The challenge section, and the document in general, would be even better if it included
a discussion of identifiers and privacy. The general concern is that because small
devices have limited resource, they end up using just one identity, maybe just one 
public key. This makes them easy to track when they move, and by extension track the
movements of their owners for wearable devices, or associated objects such as cars for
general devices. There are certainly mitigations, such as provisioning new identities
at appropriate times, or using temporary identities in communication protocols, but
these mitigations certainly require the kind of trade-offs discussed in the draft. It
would thus be very nice to introduce the privacy challenges in the "challenge"
section, and to discuss the privacy mitigations in the other sections, e.g., architecture
and provisioning.