[Suit] A few comments on draft-ietf-suit-manifest-02

Russ Housley <housley@vigilsec.com> Mon, 20 January 2020 21:32 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: suit@ietfa.amsl.com
Delivered-To: suit@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id A6F08120232 for <suit@ietfa.amsl.com>; Mon, 20 Jan 2020 13:32:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id uBINHa6L7l9C for <suit@ietfa.amsl.com>; Mon, 20 Jan 2020 13:32:54 -0800 (PST)
Received: from mail.smeinc.net (mail.smeinc.net []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5372412011D for <suit@ietf.org>; Mon, 20 Jan 2020 13:32:54 -0800 (PST)
Received: from localhost (localhost []) by mail.smeinc.net (Postfix) with ESMTP id 0833A300AFB for <suit@ietf.org>; Mon, 20 Jan 2020 16:18:53 -0500 (EST)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([]) by localhost (mail.smeinc.net []) (amavisd-new, port 10026) with ESMTP id QXBNThoc6mvZ for <suit@ietf.org>; Mon, 20 Jan 2020 16:18:51 -0500 (EST)
Received: from a860b60074bd.fios-router.home (pool-108-51-198-163.washdc.fios.verizon.net []) by mail.smeinc.net (Postfix) with ESMTPSA id 70F9D30046F for <suit@ietf.org>; Mon, 20 Jan 2020 16:18:51 -0500 (EST)
From: Russ Housley <housley@vigilsec.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Message-Id: <4AA317F5-5D50-4A28-8259-D054BD6D6435@vigilsec.com>
Date: Mon, 20 Jan 2020 16:32:51 -0500
To: suit <suit@ietf.org>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/suit/-WPqxy0-Vj9GyGS55263wj3ARlo>
Subject: [Suit] A few comments on draft-ietf-suit-manifest-02
X-BeenThere: suit@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Software Updates for Internet of Things <suit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/suit>, <mailto:suit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/suit/>
List-Post: <mailto:suit@ietf.org>
List-Help: <mailto:suit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/suit>, <mailto:suit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Jan 2020 21:32:57 -0000

I have a few comment on draft-ietf-suit-manifest-02:

General: The RFC Style Guide says to use American English spelling. Please change it now to avoid confusion later (e.g., Behaviour --> Behavior).

Section 2: Please add a sentence before all fo the definitions.  Otherwise, the "as shown here" from the RFC 8174 citation is easy to read incorrectly.

Section 2: The last 4 paragraphs are not really about conventions or terminology at the same level as the rest of the section.  They are CBOR specific, and I wonder if they would bit better toward the end of Section 4 or the beginning of Section 5 in a subsection of their own.

Section 4: The bullets and numbered items in 4.1 end with periods, but the ones in 4.2 and 4.3 do not.  Please pick one style and use it everywhere.

Section 4.2: In the five steps, is there a problem if an implementations swaps steps 1 and 2?  If so, please explain.  If not, the document should say that conforming implementations of this specification are not required to implement this algorithm, but MUST provide functionality equivalent to the external behavior resulting from this procedure. That is, any algorithm may be used by a particular implementation so long as it produces the correct result.

Section 4.2 says: "If verification and running is implemented in bootloader, then the".  Please complete the thought.

Section 4.4: I think that "specifies behaviours in a linearised form" can simply be "specifies linear behavior".

Section 4.4: I wonder if "authenticated by the appropriate identity have access to operate" is the right concept.  I think the point is that the process will reject software that is not authenticated to an identity on the ACL.

Section 5.1: RFC 4108 includes the concept of a "stale version".  Please see Section of RFC 4108.  Do we want a capability to prevent roll-back to a previous version that has a disastrous flaw?

Section 7: I find the numbering confusing.  the is a top-level "1" without a "2".  Perhaps typical outline numbering would be more clear.

Section 7 and 11: We need to come up with a presentation that will keep the line length under 73 characters.  Maybe something like:

   SUIT_Common = {
       ? suit-dependencies
             => bstr .cbor [ + SUIT_Dependency ],
       ? suit-components
             => bstr .cbor [ + SUIT_Component_Identifier ],
       ? suit-dependency-components
             => bstr .cbor [ + SUIT_Component_Reference ],
       ? suit-common-sequence
             => bstr .cbor SUIT_Command_Sequence,

Section 12: Please say in the introduction what one-way hash function is used.

Section 13: Please provide the rules for additions to each of the IANA registries that are identified.