[secdir] SecDir Review of draft-ietf-ace-usecases

Adam Montville <adam.w.montville@gmail.com> Mon, 12 October 2015 14:02 UTC

Return-Path: <adam.w.montville@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DD9B1B32A6; Mon, 12 Oct 2015 07:02:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 8PRtjlu1SRNF; Mon, 12 Oct 2015 07:02:15 -0700 (PDT)
Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91FD71B3271; Mon, 12 Oct 2015 07:02:05 -0700 (PDT)
Received: by oiar126 with SMTP id r126so36126745oia.0; Mon, 12 Oct 2015 07:02:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=OvpXsGLQ+RCuOedG/0OweA7gJNlPdmN5av3awz9tTK0=; b=MbnkPuuS1FmSQUaYjihCLVnImJuheixkL9lIzLN8pJIVH/EhUtnpICmvmg+K7vdPRm u7RY8rEmHW9jkEQQlT8P5xU1vjMEXcRBq100gJDui52YLrs8xoOs9Kr9x1mbEgPPUhcG IwQEHyjUkVBQUOdjPf+3rgNfalOEilxef5enpH2aXbMlESO62C7SkOVTp9XYdac9S/qv 0TpTf9JncxWRAcH3TNr8/Nxqq0BR6fn5v2mnEVoXT7vXWtS29KP8dIWqhGb0uFwyNm0R LQAzWhOWxKz29kV8pI2jWNsnWoPsCFSHZBy7Ws0zrIZrdEp6RN31ky99oo1tufCfrBE9 FIzA==
X-Received: by 10.202.210.208 with SMTP id j199mr11418308oig.130.1444658524971; Mon, 12 Oct 2015 07:02:04 -0700 (PDT)
Received: from macbook-pro.attlocal.net (99-64-100-131.lightspeed.austtx.sbcglobal.net. [99.64.100.131]) by smtp.gmail.com with ESMTPSA id 189sm6479085oid.14.2015.10.12.07.02.03 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 12 Oct 2015 07:02:03 -0700 (PDT)
From: Adam Montville <adam.w.montville@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Message-Id: <89DB82B6-28DB-461D-9E19-961BB883F3D5@gmail.com>
Date: Mon, 12 Oct 2015 09:02:01 -0500
To: The IESG <iesg@ietf.org>, secdir@ietf.org, draft-ietf-ace-usecases.all@tools.ietf.org
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
X-Mailer: Apple Mail (2.2104)
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/NvxdKQS1B16bCJWAr72NnefUKF0>
Subject: [secdir] SecDir Review of draft-ietf-ace-usecases
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
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: <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: Mon, 12 Oct 2015 14:02:16 -0000

Hi.

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

Draft is Ready with nits and one possible issue.

This draft seems to provide a good set of use cases collectively representing the lifecycle of constrained devices up to and including decommissioning.  

While the draft does mention “configuration”, the context is more about ensuring flexibility of expressing access permissions.  I’m not sure if this draft requires something like the following, but it would be beneficial for downstream operational processes to explicitly support endpoint posture assessment.  This could be done by providing an explicit posture-related interface.  Such a requirement could be alluded to in the Security Considerations section.  On the other hand, this may be something addressed by CoAP and other drafts.


Nits (against -09):

Second paragraph of 3.1: You might consider adding a sentence indicating whether developers are expected to do anything after becoming familiar with RFC7258.

Third paragraph of 3.1: Formatting issue after first sentence - second sentence is on a new line, or the second sentence was intended to start a new paragraph.

Third paragraph of 3.1: s/attacks/attack/

Fifth paragraph of 3.1: Formatting issue after second sentence - third sentence is on a new line, or the third sentence was intended to start a new paragraph.


Kind regards,

Adam