Re: [secdir] Security directorate review of draft-ietf-lwig-terminology-04

Ben Laurie <benl@google.com> Tue, 28 May 2013 08:47 UTC

Return-Path: <benl@google.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D241821F93A3 for <secdir@ietfa.amsl.com>; Tue, 28 May 2013 01:47:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3375QFDHboHk for <secdir@ietfa.amsl.com>; Tue, 28 May 2013 01:47:47 -0700 (PDT)
Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB3C21F93D2 for <secdir@ietf.org>; Tue, 28 May 2013 01:47:47 -0700 (PDT)
Received: by mail-ie0-f173.google.com with SMTP id k13so929389iea.32 for <secdir@ietf.org>; Tue, 28 May 2013 01:47:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=eFQhLE9mUe3DvgcDCvu03+vUG5LVSRE9EedDuuYKd78=; b=WsjKVG/nqFj4anbrJ0f2lyPV1Mhpv1WxKJSwI768NjiMhUCijstO5iGMYyK14Vw8My s12duJs0DvThE/Tim1EjqfEmjX/naxiVK+ESjn8ul4vC6rMFq1PCYSqitVD3Rp9n0L7Y xP20jAs3PYttV6Vo2BtBENxIt69Ki0y2ycubPwBXbPDZtCVGlmg3xkB8BbkuswIKdWX+ ML4dacsuNb/5sqvyr4bPcHnbcVCkHYgs6Oy6q6Oq5OytVTUdV6dTfZucCTEFIkdmOys+ OSqjdS0H8rgZ6KV9fL65FJaCItTeXm1EZ9K+7kRpV15H5B1RVpX2BFaRKfKTI02+RD9D W3YQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=eFQhLE9mUe3DvgcDCvu03+vUG5LVSRE9EedDuuYKd78=; b=EzSrFuQ2AK0YOmoyXC5zGfpLUPz1K8YDnSIrTRHLovtXNKkdy1d1lyaLBjelzt2EZC tkLgk7IRPd0mloAl/6mWjO8rlmqW8SfK6ZLcd3F6IQ86avoThF5ljnkCd3ZJlDONswp1 noJCSoxFf5pP/sO1gtXqBNNA5J0AQKzhzIjXyh3wmBA5DGZOEM0pHM+l5GMYjJDBUlTf SM5un1h2xXvsM2IYakVUOopCDPhR+Z8oAzugnVCweZc7W1OVndE/5/c7ddfKMgHoZbKC fgR6SMAw1+39ThpSJ3rfKK3rpOEF6DUonC2i1LBhXcr2XUsSwh2UlFSvtFj0puf+oX94 C5SQ==
MIME-Version: 1.0
X-Received: by 10.50.85.101 with SMTP id g5mr6425002igz.26.1369730865770; Tue, 28 May 2013 01:47:45 -0700 (PDT)
Received: by 10.64.230.232 with HTTP; Tue, 28 May 2013 01:47:45 -0700 (PDT)
In-Reply-To: <3CD078EF-9CBB-4C19-A5F6-DFC21C522EAA@tzi.org>
References: <CABrd9SQuTy-5dDBfmYa3vJCTi7a-U2nx5-b0Zfa9tKCDHxNV6Q@mail.gmail.com> <3CD078EF-9CBB-4C19-A5F6-DFC21C522EAA@tzi.org>
Date: Tue, 28 May 2013 09:47:45 +0100
Message-ID: <CABrd9SSbJ+LPMuz3KZgY5vTp+YE--D-AE9nb8WwcQZ7ydWy9eg@mail.gmail.com>
From: Ben Laurie <benl@google.com>
To: Carsten Bormann <cabo@tzi.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQnDAWmufZHxA7JlHBXmQn6ZI5zDSPu+YB6pqCJoNsDzxAHMAeyZCwa6hmiiqPeP9UK+/udk+5sZKIwhoYCg9VyPgw/k7/YZy7t6nuVfhpcD7YjFdbhCYYi1q3IKI/APrnl14bE9oV/itwVxHHQLJwDdtN24RbsrXVjVn+MPKCFmO17tbi9Q7oiRqZdpOgUxaOh6Kdjt
Cc: draft-ietf-lwig-terminology.all@tools.ietf.org, The IESG <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] Security directorate review of draft-ietf-lwig-terminology-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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: <http://www.ietf.org/mail-archive/web/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: Tue, 28 May 2013 08:47:48 -0000

On 28 May 2013 07:58, Carsten Bormann <cabo@tzi.org> wrote:
> On May 23, 2013, at 13:48, Ben Laurie <benl@google.com> wrote:
>
>> I would
>> suggest that this section could usefully contain a summary of the
>> security implications of the various constraints discussed.
>
> Ben,
>
> thanks for reminding us.
>
> Interestingly, I just put in something like this as a new subsection 11.6 in draft-ietf-core-coap-17, which I have reproduced below. That section is focused on three specific considerations.
>
> I would expect security considerations to be more actionable when discussed in the context of a specific protocol, as opposed to the terminology that is used for describing the constraints.
>
> Doing a more extensive discussion of security implications of constrainedness would be a great document on its own, which maybe we should start looking into in the LWIG WG.  There is also an activity to work on using DTLS properly in constrained environments, which would also benefit from such a document.

Sounds like a great idea (and see below).

> So I'm not sure how much we should be putting in the terminology document, but the WG will certainly need to discuss this.  I'm opening a ticket for now.

I made the observation because there are various statements about
security spread throughout the document, so clearly it is a matter
already on your minds, for example:

" Class 0 devices are very constrained sensor-like motes. Most likely
   they will not be able to communicate directly with the Internet in a
   secure manner."


>
> Grüße, Carsten
>
>
>
> 11.6.  Constrained node considerations
>
>    Implementers on constrained nodes often find themselves without a
>    good source of entropy [RFC4086].  If that is the case, the node MUST
>    NOT be used for processes that require good entropy, such as key
>    generation.  Instead, keys should be generated externally and added
>    to the device during manufacturing or commissioning.

As it happens, I'm a FreeBSD developer and in the wake of the recent
low entropy attacks we had quite some discussion about constrained
nodes ... one thing we thought would be of great benefit was, rather
than create keys during manufacturing, add entropy - i.e. include a
block of randomness in the ROM (or whatever) that's unique per device.
Assuming the device itself is not physically attacked, even quite a
small amount (say 256 bits) would be sufficient for the lifetime of
the device, particularly when mixed with what little is available from
the environment. Note that it is important to mix in a counter of some
kind so the entropy is not re-used unmodified.

>    Due to their low processing power, constrained nodes are particularly
>    susceptible to timing attacks.  Special care must be taken in
>    implementation of cryptographic primitives.
>
>    Large numbers of constrained nodes will be installed in exposed
>    environments and will have little resistance to tampering, including
>    recovery of keying materials.  This needs to be considered when
>    defining the scope of credentials assigned to them.  In particular,
>    assigning a shared key to a group of nodes may make any single
>    constrained node a target for subverting the entire group.

This is another reason per-device entropy is useful (clearly nothing
can defend against any particular device that's been tampered with -
for starters, it could easily be replaced with a malicious version).