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

Eliot Lear <lear@cisco.com> Fri, 05 June 2020 16:15 UTC

Return-Path: <lear@cisco.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 756A43A07DF for <suit@ietfa.amsl.com>; Fri, 5 Jun 2020 09:15:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.601
X-Spam-Level:
X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 k6ODn59E1r7U for <suit@ietfa.amsl.com>; Fri, 5 Jun 2020 09:15:14 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20ED33A07DC for <suit@ietf.org>; Fri, 5 Jun 2020 09:15:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4525; q=dns/txt; s=iport; t=1591373714; x=1592583314; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=CWyRhuRvDMW557BPKEzUBj1enuyme/Ctqs938+bh8AQ=; b=kJjb1NapjRPO3mGuOjrqLTU7vTgmsQK3bMerQxg3XPAIuX3d/tbKmn07 coLHgFVaPXQB7QnplZUPwww8LWMe2EX//XahM7fdYKoITlRVUHFUnt8DE 0p/ZzbOFkBouHhXqD651WbGJqOQuUwuoQDrUE2ctK6MEoOBDevfwyzWBb w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEBQB1btpe/xbLJq1jAxwBAQEBAQE?= =?us-ascii?q?HAQESAQEEBAEBQIFKgxpUASASLIQliQGHYyWJfpAVgWgLAQEBDAEBHxAEAQG?= =?us-ascii?q?BUIJ0AoI1JTgTAgMBAQsBAQUBAQECAQYEbYVbDIVyAQEBAQIBI1YFBwQLEQE?= =?us-ascii?q?DAQEBAgImAgIhKAYIBhMbgwsBgksDDiAPsgV2gTKIVg2CIoEOKoYchiEpggC?= =?us-ascii?q?BEScMEIFPUC4+gh6BewESASEhJoJNM4ItBJFFoW1MgmOCfYp/hiKEYwMdgme?= =?us-ascii?q?Ne41fkmGKbY1vg00CBAYFAhWBaiJmcDMaCBsVOyoBgj4JNRIZDZBMF4NPilg?= =?us-ascii?q?/AzACNQIGAQcBAQMJj0kBAQ?=
X-IronPort-AV: E=Sophos;i="5.73,476,1583193600"; d="scan'208";a="26795088"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 05 Jun 2020 16:15:10 +0000
Received: from [10.61.199.107] ([10.61.199.107]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 055GF6Kh026233 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 5 Jun 2020 16:15:07 GMT
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Eliot Lear <lear@cisco.com>
In-Reply-To: <1076601d63b3a$d53f5d90$7fbe18b0$@reliableenergyanalytics.com>
Date: Fri, 5 Jun 2020 18:15:06 +0200
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>
Content-Transfer-Encoding: quoted-printable
Message-Id: <BF5D5E46-4A7C-44A7-8554-5DE1E03A3F21@cisco.com>
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>
To: Dick Brooks <dick@reliableenergyanalytics.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-Outbound-SMTP-Client: 10.61.199.107, [10.61.199.107]
X-Outbound-Node: aer-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/suit/fhVPSvwvnLhAMZpgRmJUoLxk4e8>
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 16:15:16 -0000

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 =-
> 
> 
> 
>