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

Carsten Bormann <> Tue, 28 May 2013 06:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 16D3221F8511; Mon, 27 May 2013 23:58:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.249
X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HmfzcscmUGQu; Mon, 27 May 2013 23:58:46 -0700 (PDT)
Received: from ( [IPv6:2001:638:708:30c9::12]) by (Postfix) with ESMTP id 6269421F9007; Mon, 27 May 2013 23:58:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id r4S6wc9i018073; Tue, 28 May 2013 08:58:38 +0200 (CEST)
Received: from [] ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 5E90334A4; Tue, 28 May 2013 08:58:38 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
Content-Type: text/plain; charset=iso-8859-1
From: Carsten Bormann <>
In-Reply-To: <>
Date: Tue, 28 May 2013 08:58:36 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Ben Laurie <>
X-Mailer: Apple Mail (2.1503)
Cc:, The IESG <>, "" <>
Subject: Re: [secdir] Security directorate review of draft-ietf-lwig-terminology-04
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 28 May 2013 06:58:52 -0000

On May 23, 2013, at 13:48, Ben Laurie <> wrote:

> I would
> suggest that this section could usefully contain a summary of the
> security implications of the various constraints discussed.


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.

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.

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.

   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.