Re: [Suit] How are firmware and firmware versions expressed in manifest?

Dick Brooks <dick@reliableenergyanalytics.com> Fri, 05 June 2020 13:11 UTC

Return-Path: <dick@reliableenergyanalytics.com>
X-Original-To: suit@ietfa.amsl.com
Delivered-To: suit@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A00F3A0849 for <suit@ietfa.amsl.com>; Fri, 5 Jun 2020 06:11:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com
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 7bxK1RQihuIa for <suit@ietfa.amsl.com>; Fri, 5 Jun 2020 06:11:35 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28B863A0846 for <suit@ietf.org>; Fri, 5 Jun 2020 06:11:35 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id ADF325C0175; Fri, 5 Jun 2020 09:11:33 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Fri, 05 Jun 2020 09:11:33 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=ehVlZA0VnrzB/G8C+UxXWUFFiAbVcPimuE5rX5ZI4 Fw=; b=GpJkBOB0cUTgNULbpYZtYX4w3C/CEBURZ2GdCPK+uFix7U7KvvyOjstpA xmLCOcUboPwTtFrxk60/ijUpqUm784qq0PWzDzHU+pfY4poONje345jurggP/j+N qL3bKGJyLsfsNVeoQfM5UEuaQnAKkH/pMLJhuaXKQjsdQjoyZsN1OiicTF6C5UI4 hCa19L6+5sVUl58XyAMNml0RzF+jtdUZ3X3De66wHH97VUAbzFl0xHUbhY/SPB2Q CQbMC+ysQNndlddAY1THnQrYzyO9qFI2qmz8sYXu1YmWsKNH+gcYX4EzKCQDtAXh Aw8MreAq7TN/i+23LurT0vf/PITBA==
X-ME-Sender: <xms:hUTaXuFpBqwWy2_EncuLj24kW2f5pbw-XKgIdeeSHw-Krm7scXC0nw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudegfedghedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvfhgjufffohfkgggtgffothesthejredtvddtvdenucfhrhhomhepfdff ihgtkhcuuehrohhokhhsfdcuoeguihgtkhesrhgvlhhirggslhgvvghnvghrghihrghnrg hlhihtihgtshdrtghomheqnecuggftrfgrthhtvghrnhepvdejudeigeehuddtkedvtefh udekkeehleeigefggfdvgfejleekfefgleegfeelnecuffhomhgrihhnpehrvghlihgrsg hlvggvnhgvrhhghigrnhgrlhihthhitghsrdgtohhmnecukfhppedvudeirdduleefrddu gedvrddvvdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpeguihgtkhesrhgvlhhirggslhgvvghnvghrghihrghnrghlhihtihgtshdrtghomh
X-ME-Proxy: <xmx:hUTaXvVWPQNvNGeszzdN-1QDFF7mc_JVHfnYzJPgpVgUZoqlEQ3G-g> <xmx:hUTaXoJ8ehSZLa8dly5gyPBCGZCobG0FB7kC8OKsbsSsCgbDPEySNg> <xmx:hUTaXoE7v4zzGoHX_BC4yvUSNcwP8hArwptS9E6BdLv1aJpXdN0UZg> <xmx:hUTaXvfVl75NsGXesHu01oVuBLhwQ2GJwrHWhbNBhyk3jy_til8ggg>
Received: from farpoint (unknown [216.193.142.22]) by mail.messagingengine.com (Postfix) with ESMTPA id D0E6E3060FE7; Fri, 5 Jun 2020 09:11:32 -0400 (EDT)
From: "Dick Brooks" <dick@reliableenergyanalytics.com>
To: "'Michael Richardson'" <mcr+ietf@sandelman.ca>, "'Hannes Tschofenig'" <Hannes.Tschofenig@arm.com>, <suit@ietf.org>, "'Saad EL JAOUHARI'" <saadeljaou@gmail.com>, "'Eliot Lear'" <lear@cisco.com>, "'Henk Birkholz'" <henk.birkholz@sit.fraunhofer.de>
References: <AM0PR08MB371631B7C1E6B50DCA29049AFA880@AM0PR08MB3716.eurprd08.prod.outlook.com> <8b6d01d639d0$62614150$2723c3f0$@reliableenergyanalytics.com> <AM0PR08MB37166AD36B5AA36EA7D7CA9BFA890@AM0PR08MB3716.eurprd08.prod.outlook.com> <20437.1591317129@localhost>
In-Reply-To: <20437.1591317129@localhost>
Date: Fri, 5 Jun 2020 09:11:28 -0400
Organization: Reliable Energy Analytics
Message-ID: <1076601d63b3a$d53f5d90$7fbe18b0$@reliableenergyanalytics.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQEpJGg3Q76y3b59AZfDOO6eGr7fRAJUo0s2Am+d4lkB06Pk1Knval0Q
Content-Language: en-us
Archived-At: <https://mailarchive.ietf.org/arch/msg/suit/Bs7UexGq8XlfG8C-Bckefwznd00>
Subject: Re: [Suit] How are firmware and firmware versions expressed in manifest?
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: Fri, 05 Jun 2020 13:11:37 -0000

Thanks, Michael Richardson. I'm uncertain that MUD has exactly what I'm
looking for to meet NERC CIP-010-3 R1, Part 1.6 expectations, after a
cursory look at the standard. I don't see where the MUD process would
support deep introspection and corroborating evidence within a risk
assessment control prior to deployment, which is what I need for NERC
CIP-010-3. The base case I'm working with is where a device in the Bulk
Electric System (BES) has been acquired and deployed, that contains a
firmware component. A patch has been distributed for that firmware and a
grid operator wants to perform a risk assessment on the patch before any
attempt at deployment. 

I'm still thinking that SUIT may be more appropriate than MUD for this use
case, but I may be missing an important point. Can you provide a distinction
between MUD and SUIT that would apply to the use case I describe, to help me
understand your assertion that MUD may be more appropriate than SUIT? 

I genuinely just want to find the best solution to the problem I'm trying to
solve, whatever that turns out to be.

Wonderful thing about standards, there are so many to choose from!

Thanks,

Dick Brooks

Never trust software, always verify and report! T
http://www.reliableenergyanalytics.com
Email: dick@reliableenergyanalytics.com
Tel: +1 978-696-1788

-----Original Message-----
From: Michael Richardson <mcr+ietf@sandelman.ca> 
Sent: Thursday, June 04, 2020 8:32 PM
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>om>; Dick Brooks
<dick@reliableenergyanalytics.com>om>; suit@ietf.org; 'Saad EL JAOUHARI'
<saadeljaou@gmail.com>om>; Eliot Lear <lear@cisco.com>om>; Henk Birkholz
<henk.birkholz@sit.fraunhofer.de>
Subject: Re: [Suit] How are firmware and firmware versions expressed in
manifest?


Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:
    > * Finally, there is also a version condition. This allows to express
    > that a manifest is applicable to one or multiple versions of the
    > firmware. As described in the information model draft, this situation
    > occurs when you upload an application that relies on existing software
    > to be present on the device. (Think of it as an API version.)

    > It is important to note that the manifest is not meant to be used to
    > describe the software running on the device. This is the job of other
    > tools, such as COSWID. The manifest instead provides instructions on
    > how to update firmware and to accomplish secure boot.

There are some efforts to include RFC8520 (MUD) definitions into the
Manifest, either by value or reference. (Henk!)

There are other efforts to include CoSWID into RFC8520, I think.
I may be mistaken as to the direction of the arrows here.

    DB> I'm hoping to use the manifest as a virtual SBOM. Will let you know
    DB> if I'm successful in this regard.

The manifest could include a reference to a SBOM, but I don't think it is
reasonable to to include it by value.  I think that the right place to get
the SBOM is via an RFC8520 (MUD) object.

I think that it would help if SUIT considered how some BCPs and/or
Applicability statements that helped to tie some things together.
(Specifically, from the charter:
       This group will not define any new transport or discovery mechanisms,
       but may describe how to use existing mechanisms within the
architecture.
)
A lot of Enterprises would like to cache all firmware contents somewhere
locally, avoiding external access for devices.  There is an overlap here
with processes that might report on success updates, caching the new SBOMs
into an audit system, etc.

--
Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works  -=
IPv6 IoT consulting =-