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

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 09 June 2020 16:40 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 1E59B3A0985 for <suit@ietfa.amsl.com>; Tue, 9 Jun 2020 09:40:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 8Kgg-cUtK1k1 for <suit@ietfa.amsl.com>; Tue, 9 Jun 2020 09:40:18 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5B453A0905 for <suit@ietf.org>; Tue, 9 Jun 2020 09:40:18 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 65B8138A32; Tue, 9 Jun 2020 12:37:48 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id qms6aP1XO3ik; Tue, 9 Jun 2020 12:37:47 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 4C885389B2; Tue, 9 Jun 2020 12:37:47 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 8934B696; Tue, 9 Jun 2020 12:40:15 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Eliot Lear <lear@cisco.com>, Hannes Tschofenig <Hannes.Tschofenig@arm.com>, "suit\@ietf.org" <suit@ietf.org>
In-Reply-To: <224F26E6-D4C3-4B10-A343-71D55E1A2EE2@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> <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>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Date: Tue, 09 Jun 2020 12:40:15 -0400
Message-ID: <29195.1591720815@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/suit/pLAIdYDuSEXqpPh0_Y_njmHp_9I>
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 16:40:22 -0000

Eliot Lear <lear@cisco.com> wrote:
    > 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.

Let me tell you as an opensource software maintainer, that I get CVEs to
review that apply to version Y of product Z which is of class "SSL VPN",
and yet, the CVE people will pattern matched on "VPN", and assumed it
must apply to IPsec systems too.  The WTF level is ridiculous.
The cost of review is serious and signficant, particularly as the details are
often really hard to find.

VEX will be a good thing.
Being able to sign them would be awesome.

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