Re: [Suit] next steps in clarifying scoping terminology for SUIT, CoSWID, MUD and SBOM

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 09 June 2020 17:41 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 8DA713A0B24; Tue, 9 Jun 2020 10:41:12 -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 k0s33aMMrKCJ; Tue, 9 Jun 2020 10:41:08 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89EB83A0AFD; Tue, 9 Jun 2020 10:41:08 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id C5F8638A39; Tue, 9 Jun 2020 13:38:37 -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 1k1mR_FumJui; Tue, 9 Jun 2020 13:38:36 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 470F938A36; Tue, 9 Jun 2020 13:38:36 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 867C9696; Tue, 9 Jun 2020 13:41:04 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: lwip@ietf.org, suit@ietf.org, opsawg@ietf.org, sacm@ietf.org
Reply-To: lwip@ietf.org
In-Reply-To: <22789.1591719213@localhost>
References: <22789.1591719213@localhost>
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 13:41:04 -0400
Message-ID: <12658.1591724464@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/suit/pJBYiynJZxEcvTzB8O0Nnp5FV2w>
Subject: Re: [Suit] next steps in clarifying scoping terminology for SUIT, CoSWID, MUD and SBOM
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 17:41:14 -0000

{Annoyingly, the LWIG wg's ML is LWIP@ietf.org.
We gotta stop own-goals like this.
My appologies for repeating myself}

{I've set the reply-to to lwig, which I think is appropriate}

SUIT aims at devices where the firmware can be updated as one (or a counted
on fingers few) blob.  This is a good constraint, and because it's a "few"
blobs, the edge isn't overly sharp.

For instance, we have a common understanding that while SUIT is inappropriate
for Smartphone APPs, it is appropriate for the core "System", "Rescue" and
"Radio/Broadband" images that are typical for phones.
Such smartphones do not fit into RFC7228, and yet they are not "unconstrained"

We constrast SUIT to devices where the is potentially many packages that
can be updated, up to and including the Linux/Windows desktop/server
environment where there are potentially thousands of packages.

In RFC7228, we described a series of useful terms and classes, and we have
repeatedly come back wishing to have some notions of "class 3+" to describe
classes of more capable devices, up to and including "classic" desktop and
server OS installations.

I think that as we move towards dealing with SBOM concepts (whether via
CoSWID, or in liason to IoTSF and/or NTIA) that it would be useful if we
worked on an rfc7228bis (or a companion document: nothing wrong with 7228 really),
that allowed us to speak more intelligently about different classes of
devices.

I believe that this should go to the point of having an IANA Registry
for the class types, and that RFC8520(MUD) and maybe CoSWID would want to
assert such a thing.  And probably into some other netmod protocol.

Given device FOO on one's Enterprise network, which seems to have a
vulnerability, how does one upgrade it?

Forklift? JTAG cable? OTA via custom protocol? OTA with SUIT?
"apt-get"? "windows-update"? Can device download while it is operational?

For instance, my impression is that 90% of Industrial/Smart-City IoT devices
in a space way above class 2 (a class 4 or 5!) which are essentially a
RPI/Grapeboard/equivalent.  In the *best case* running a Yocto build with
many many input packages, but only a single image on the output.  In a worst
case, they are literally Raspberry PI running Raspbian, and dpkg, with
the resulting SDcard getting cloned.

These devices are hardwired/cabled manually, or experience two-touch
onboarding to WiFI or Lora... and they talk back to some cloud provided
system that itself may have an unknown set of packages.

The SBOM situation could not be worse: it would not surprise me to find
gnutls, openssl and gpg crypto on the target system, each with their
own copy a RSA and ECDSA encrypt,  and should some new oracle/etc. kind
of attack to come along, that devices in the field will be completely
unevenly patched.

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