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

Dick Brooks <dick@reliableenergyanalytics.com> Fri, 05 June 2020 17:22 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 9BF973A0A36 for <suit@ietfa.amsl.com>; Fri, 5 Jun 2020 10:22:19 -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 TpYQhV3K95ns for <suit@ietfa.amsl.com>; Fri, 5 Jun 2020 10:22:18 -0700 (PDT)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D54873A09F4 for <suit@ietf.org>; Fri, 5 Jun 2020 10:22:17 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 2C1A75C00E0; Fri, 5 Jun 2020 13:22:17 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Fri, 05 Jun 2020 13:22:17 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=SVjwiYyRA64vfl+LXFnGWd9HqjnVKKEfln6SBB14T AE=; b=iQHZ9vCzir/ckymZw+i5rvi+jIbBBYb7uQBJMyIpbux19D+TCYs+E9vtA VBFn413Ryx4WbdSnxUHKC6rIl3DS1V4aNzxWwmjJxURZtIEA2X0/fgPj0tdP/v7F 84DXib881hv9VIQWVD6NEnoy1ETKvv/UFgx48XP8vK961pri/ADg2KcelD5aeODS 1p2fWoOnAVovZHoHnws8n7TFbTnPsx6hmo1CZ+BUpBorjCM+54t7C4/KMD4d6ceX 3KJnC9Hphmk1PS4HKKrgiwgDaMmsAP4agbv02w9vkqAZy3nm7RI7QX+USFFVsqIp OIRD84TPcMtiV8ZylFyc3RvwfWMxw==
X-ME-Sender: <xms:SH_aXtRYQzQV9m6MjsSUgT9Ngte0L9XW-5pzIOBWQX7c9uyqnnbE6g>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudegfedgleekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvfhgjufffohfkgggtgffothesthhqredtvddtjeenucfhrhhomhepfdff ihgtkhcuuehrohhokhhsfdcuoeguihgtkhesrhgvlhhirggslhgvvghnvghrghihrghnrg hlhihtihgtshdrtghomheqnecuggftrfgrthhtvghrnhepjeetffetfeduieelhfelieef vefgfeevgeetledttefhuefggfffhfehveeluefgnecuffhomhgrihhnpehrvghlihgrsg hlvggvnhgvrhhghigrnhgrlhihthhitghsrdgtohhmnecukfhppedvudeirdduleefrddu gedvrddvvdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpeguihgtkhesrhgvlhhirggslhgvvghnvghrghihrghnrghlhihtihgtshdrtghomh
X-ME-Proxy: <xmx:SH_aXmxm4cX_lTPPgZmI8o_BC1CIqO3cVuYxDJdt_JEcO9ruJ0x3YQ> <xmx:SH_aXi387c1VnyhE70QI37N8I4-DfmsYG6MciU6COkixN0rCbsOd9w> <xmx:SH_aXlA5REPI8xz7u6muSxHcsU34sH97Xivj7qC03nUgJ7fS04Tixw> <xmx:SX_aXqYeSx-sxJTAFXik7mxOGSGaO_dwL-pgWLBcY_EpaVCkm7aVjA>
Received: from farpoint (unknown [216.193.142.22]) by mail.messagingengine.com (Postfix) with ESMTPA id 069B5328005E; Fri, 5 Jun 2020 13:22:16 -0400 (EDT)
From: "Dick Brooks" <dick@reliableenergyanalytics.com>
To: "'Eliot Lear'" <lear@cisco.com>
Cc: "'Michael Richardson'" <mcr+ietf@sandelman.ca>, "'Hannes Tschofenig'" <Hannes.Tschofenig@arm.com>, <suit@ietf.org>, "'Saad EL JAOUHARI'" <saadeljaou@gmail.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> <1076601d63b3a$d53f5d90$7fbe18b0$@reliableenergyanalytics.com> <BF5D5E46-4A7C-44A7-8554-5DE1E03A3F21@cisco.com>
In-Reply-To: <BF5D5E46-4A7C-44A7-8554-5DE1E03A3F21@cisco.com>
Date: Fri, 5 Jun 2020 13:22:11 -0400
Organization: Reliable Energy Analytics
Message-ID: <11b6b01d63b5d$db8f5790$92ae06b0$@reliableenergyanalytics.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQEpJGg3Q76y3b59AZfDOO6eGr7fRAJUo0s2Am+d4lkB06Pk1ADWaYOUAhdO83Cp2ERBQA==
Content-Language: en-us
Archived-At: <https://mailarchive.ietf.org/arch/msg/suit/Zpg1VunkVlKmXXCl18sz51971Es>
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 17:22:20 -0000

Thanks, Eliot. JSON is a fine medium. 

Will the MUD/JSON blob exist within the same sphere of provenance as the actual software object it describes? The chain of trust is key for both the software/firmware object and it's MUD metadata. Ideally the integrity and authenticity "lock" covers both objects. 

Thanks,

Dick Brooks

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

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

Dick,

Think of MUD as nothing more than a JSON blob that points at things or otherwise provides guidance to the deployment about the device.  It’s quite generic.  One of the things it can point to is how to retrieve a software bill of materials.  Another thing it can point to is a list of certifications.  If JSON scares you, it wouldn’t be that hard to serialize into CBOR.

Eliot



> On 5 Jun 2020, at 15:11, Dick Brooks <dick@reliableenergyanalytics.com> wrote:
> 
> 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 =-
> 
> 
> 
>