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

Dick Brooks <dick@reliableenergyanalytics.com> Tue, 09 June 2020 14:18 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 6E1DC3A03F2 for <suit@ietfa.amsl.com>; Tue, 9 Jun 2020 07:18:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 DuGjzLMsGrd5 for <suit@ietfa.amsl.com>; Tue, 9 Jun 2020 07:18:26 -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 619FE3A00B3 for <suit@ietf.org>; Tue, 9 Jun 2020 07:18:26 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 9A12C5C0097; Tue, 9 Jun 2020 10:18:25 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Tue, 09 Jun 2020 10:18:25 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=/K7czX eIts98aw2QKQuHCvqG3fBrQwhWTO9sBZRvQMQ=; b=eSvA6+/Lv8V1iGqIrn6rrt a9wkG+qZLUAK0vzTIZ97GsYubEb6mMxhLYAn9EvYGt/9fgmn4mCUiQr7TmIvtIzz Lx3aYUwKIv0RUa14hHYkpfL/8HQqpVOiP6tmNg+K4z9YWGAh5aaFXPQ6jo+BMo1N 7JtA/x1FBkWx2CDmmp0hBslPMVhq0FjrWPbXFhnVDPh1roVeYLpqfx5p+VVIX7Kt RsDMaJcoI/FAKTfdU+3WoDb2Ncbqid3BVptTHgtr+1OYR647BQ6bpJRMLakZzav0 DzzOfLLxtFX4C5QxTmBPLrybbKeZjj/Jx91O1YzkISl+SMBGAvBPHPEMWd9QuD6A ==
X-ME-Sender: <xms:MJrfXsPW7xu5uHG4aVgeRihJ_r1ihiwwpCpGUyqe38NNkV75IfIVWg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudehgedgjeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvfhgjufffohfkgggtofhtsehrtdhgpedvtdejnecuhfhrohhmpedfffhi tghkuceurhhoohhkshdfuceoughitghksehrvghlihgrsghlvggvnhgvrhhghigrnhgrlh ihthhitghsrdgtohhmqeenucggtffrrghtthgvrhhnpedtteefjefffeeivdeigffflefg heekiedvffefleffheegkeeufedvtdfgudffleenucffohhmrghinheprhgvlhhirggslh gvvghnvghrghihrghnrghlhihtihgtshdrtghomhenucfkphepvdduiedrudelfedrudeg vddrvddvnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh epughitghksehrvghlihgrsghlvggvnhgvrhhghigrnhgrlhihthhitghsrdgtohhm
X-ME-Proxy: <xmx:MJrfXi-_y71iNU36uPTEgrxWFjXtDGEzr-5wNk0ANE7CKlBOmVUdsA> <xmx:MJrfXjT5ONYi9f9P4I97MHtuuCO1CaY-cW-hnIZ2Rhto2XXraYhnKw> <xmx:MJrfXks_-n4yhu-9PGXGvkVnr_pvTecFxtidj3d77ZS_fFLSHVUKWg> <xmx:MZrfXuoIkUUBHlRL_9j6LqvWfLApEVwNa1E53eCwHD9vesc8abYNoQ>
Received: from farpoint (unknown [216.193.142.22]) by mail.messagingengine.com (Postfix) with ESMTPA id 7C33F306218B; Tue, 9 Jun 2020 10:18:24 -0400 (EDT)
From: "Dick Brooks" <dick@reliableenergyanalytics.com>
To: "'Eliot Lear'" <lear=40cisco.com@dmarc.ietf.org>, "'Hannes Tschofenig'" <Hannes.Tschofenig@arm.com>
Cc: "'Michael Richardson'" <mcr+ietf@sandelman.ca>, <suit@ietf.org>
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> <AM0PR08MB3716C555048993639B14D76FFA860@AM0PR08MB3716.eurprd08.prod.outlook.com> <5820.1591393073@localhost> <AM0PR08MB3716939E832E5483CB8575EBFA870@AM0PR08MB3716.eurprd08.prod.outlook.com> <5789.1591484358@localhost> <AM0PR08MB3716D94B177DA76F0512D824FA850@AM0PR08MB3716.eurprd08.prod.outlook.com> <224F26E6-D4C3-4B10-A343-71D55E1A2EE2@cisco.com>
In-Reply-To: <224F26E6-D4C3-4B10-A343-71D55E1A2EE2@cisco.com>
Date: Tue, 9 Jun 2020 10:18:20 -0400
Organization: Reliable Energy Analytics
Message-ID: <000001d63e68$d5d67190$818354b0$@reliableenergyanalytics.com>
MIME-Version: 1.0
Content-Type: multipart/related; boundary="----=_NextPart_000_0001_01D63E47.4EC65830"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQEpJGg3Q76y3b59AZfDOO6eGr7fRAJUo0s2Am+d4lkB06Pk1ADWaYOUAhdO83ACM65vWAF5pebOAo/piAQCuLadxwEldBKmAnje01ypebYLYA==
Content-Language: en-us
Archived-At: <https://mailarchive.ietf.org/arch/msg/suit/2UtU_AvppnJMTI-HiLb2SnQIh28>
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: Tue, 09 Jun 2020 14:18:29 -0000

I agree with Eliot on this point “I like the concept, because in industrial much of the tooling is already flagging quite a lot of false positive CVEs.”

 

The current vulnerability reporting domain has a very poor signal/noise ratio (lots of false positives) and the latency between vulnerability discovery and CVE data repository awareness can be significantly longer than it should be to effectively mitigate a vulnerability.

 

This is perhaps the biggest problem I’m facing, making it difficult to determine an accurate trustworthiness level (score) for a software object.

 

I have to agree; MUD – what were you drinking when that became the best choice?

 

Thanks,

 

Dick Brooks



 <https://reliableenergyanalytics.com/products> Never trust software, always verify and report! ™

 <http://www.reliableenergyanalytics.com/> http://www.reliableenergyanalytics.com

Email:  <mailto:dick@reliableenergyanalytics.com> dick@reliableenergyanalytics.com

Tel: +1 978-696-1788

 

From: Suit <suit-bounces@ietf.org> On Behalf Of Eliot Lear
Sent: Tuesday, June 09, 2020 5:27 AM
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>ca>; suit@ietf.org
Subject: Re: [Suit] How are firmware and firmware versions expressed in manifest?

 

Hannes





On 8 Jun 2020, at 13:27, Hannes Tschofenig <Hannes.Tschofenig@arm.com <mailto:Hannes.Tschofenig@arm.com> > wrote:

 

I have to look at the links Eliot shared but I hope that people are not overly excited about the value of having information about what software version is on their devices for the purpose of drawing security conclusions. You have been at many hackathons where we created firmware for Cortex M-class devices and we used, for example, Mbed TLS in many instances. Does this tell you anything about the security? Can you draw conclusions when you hear that version X has a security vulnerability? Should you be concerned when a security researcher was able to mount a fault injection attack against a specific MCU with a specific version of Mbed TLS running on it? No, not really because you have to know what compile-time configurations were used to build the firmware, what hardware it is running on and what run-time configuration is present.

 

Actually, the people who should be concerned are the manufacturers, who are going to receive calls from customers who have learned that the manufacturer used EmbedOS but didn’t know that the option in a particular device is disabled.  This is an aspect of SBOMs that is understood to be problematic, and so discussion is gradually shifting to something they call Vulnerability EXchange (VEX) (I hate the name, but as someone who created something called MUD I have no real leg to stand on).  The idea behind VEX, fuzzy as it is, is that one would be able to query to determine if the manufacturer has investigated and affirmatively determined whether a particular product has a particular vulnerability.  I like the concept, because in industrial much of the tooling is already flagging quite a lot of false positive CVEs.

 

Eliot