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

Eliot Lear <> Tue, 09 June 2020 09:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 551463A07AA for <>; Tue, 9 Jun 2020 02:27:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.6
X-Spam-Status: No, score=-9.6 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id msPMIqJ2BMRT for <>; Tue, 9 Jun 2020 02:27:15 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AE6A13A0528 for <>; Tue, 9 Jun 2020 02:27:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=5033; q=dns/txt; s=iport; t=1591694834; x=1592904434; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=1lZkJuYqRzW6RvjIPsXvRRYrfAjduqFNv7FwuK5UMrw=; b=XocA/+UiTEL6wFEmvO+0+oNoRVyGq0ArwW2LRZcMvjatpJSGoHbXwlel XAKUcu7214tClUndsb5CjHV5xny3FcURahp53A//5yxSBoCUnEoLlwM+q C9612zuej8dKVkkRMxZ00wGkp1qs7LtF07fDAsjzXMEfPjnu05TslRcdG c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos; i="5.73,491,1583193600"; d="scan'208,217"; a="24529719"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Jun 2020 09:27:01 +0000
Received: from ( []) by (8.15.2/8.15.2) with ESMTPS id 0599R08v021970 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 9 Jun 2020 09:27:01 GMT
From: Eliot Lear <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_99649FEE-C81B-4A21-9CAA-B444F7A69CE0"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Date: Tue, 9 Jun 2020 11:27:00 +0200
In-Reply-To: <>
Cc: Michael Richardson <>, "" <>
To: Hannes Tschofenig <>
References: <> <8b6d01d639d0$62614150$2723c3f0$> <> <20437.1591317129@localhost> <1076601d63b3a$d53f5d90$7fbe18b0$> <> <> <5820.1591393073@localhost> <> <5789.1591484358@localhost> <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [Suit] How are firmware and firmware versions expressed in manifest?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Software Updates for Internet of Things <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 09 Jun 2020 09:27:16 -0000


> On 8 Jun 2020, at 13:27, Hannes Tschofenig <> 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.