Re: [Suit] next steps in clarifying scoping terminology for SUIT, CoSWID, MUD and SBOM
Dick Brooks <dick@reliableenergyanalytics.com> Tue, 09 June 2020 16:36 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 AF1F63A0905; Tue, 9 Jun 2020 09:36:27 -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, RCVD_IN_DNSWL_BLOCKED=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 R0lYNPZM8wd2; Tue, 9 Jun 2020 09:36:24 -0700 (PDT)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9879F3A08AD; Tue, 9 Jun 2020 09:36:24 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id E73BF5C00B7; Tue, 9 Jun 2020 12:36:23 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Tue, 09 Jun 2020 12:36:23 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding: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=zS+nZ4v/vOoHONwbYGPBsXEGrq+EPW0iajwHHBMis uo=; b=Uo3YMhJLxgIsgBQV0yK4HplP07vknNxfR7CjGWOLQ9VJqH4u9nYqdDN5f vF+9xO5nMYN8C23PlxobLiYmRoFkL0YZzXNTlleOFOktXKaCn+N/SLrzM1FLZrKM DNwHcGwV9L/9cgeSQZzpJa+r3hW6m2M4goXbrY/ZRdgKM2K0dWunvEpeGdS54caF cCqYwLYnecX3dNcYMpnQFVUe1PVq7/7ACjMne8YUWHQ+hyo6i75Pf6Jns+7MIZud LinTzIgCd55KKt9YWE+jzbVe3S92wJUW+fczQh+Gvl0OIquOOL1fZ8FITwKHMIeo 3HHc9df0IOCTqJDZRcp5exHwvdmUA==
X-ME-Sender: <xms:h7rfXrlWa46Wo628hno_aBt2kc14xajPuDfcgFMPBP8_1vmihxzhvw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudehgedguddtgecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhephffvfhgjufffohfkgggtgffoth esthejghdtvddtvdenucfhrhhomhepfdffihgtkhcuuehrohhokhhsfdcuoeguihgtkhes rhgvlhhirggslhgvvghnvghrghihrghnrghlhihtihgtshdrtghomheqnecuggftrfgrth htvghrnhepgedukeeujeelvdfftddvveegheeihfffffdujedthffgtdegkeevjeffgeeh hefhnecuffhomhgrihhnpehrvghlihgrsghlvggvnhgvrhhghigrnhgrlhihthhitghsrd gtohhmnecukfhppedvudeirdduleefrddugedvrddvvdenucevlhhushhtvghrufhiiigv pedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpeguihgtkhesrhgvlhhirggslhgvvghnvg hrghihrghnrghlhihtihgtshdrtghomh
X-ME-Proxy: <xmx:h7rfXu0-ILwi6o_iARwP8eG5J9POwMo2lrwBfUgN3en_q_qZstYEoQ> <xmx:h7rfXhoRIJJoUelUaUReSOg3Am8hHsVyEAK2neweRlOUwyxGJ4EuZA> <xmx:h7rfXjkQ4JsB26zjLngEU7Oy2g6Rnv904VFbKbqXhad5p_ac8A930g> <xmx:h7rfXmiCQgJiJ1scTqJdYTIktOcVcwpkALe_PrHww6P064I_pLSkAA>
Received: from farpoint (unknown [216.193.142.22]) by mail.messagingengine.com (Postfix) with ESMTPA id 8163530618C1; Tue, 9 Jun 2020 12:36:23 -0400 (EDT)
From: Dick Brooks <dick@reliableenergyanalytics.com>
To: lwig@ietf.org, suit@ietf.org, opsawg@ietf.org, sacm@ietf.org
References: <22789.1591719213@localhost>
In-Reply-To: <22789.1591719213@localhost>
Date: Tue, 09 Jun 2020 12:36:20 -0400
Organization: Reliable Energy Analytics
Message-ID: <013201d63e7c$1cb1ced0$56156c70$@reliableenergyanalytics.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQGbwf3yKibs4Vd6QV5H3AFmUN06yqlFdBfA
Content-Language: en-us
Archived-At: <https://mailarchive.ietf.org/arch/msg/suit/V-v5GgRJR_Dl6BR4ySyLMOfvOXc>
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 16:36:28 -0000
+1 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: Suit <suit-bounces@ietf.org> On Behalf Of Michael Richardson Sent: Tuesday, June 09, 2020 12:14 PM To: suit@ietf.org; lwig@ietf.org; opsawg@ietf.org; sacm@ietf.org Subject: [Suit] next steps in clarifying scoping terminology for SUIT, CoSWID, MUD and SBOM {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>, Sandelman Software Works -= IPv6 IoT consulting =-
- [Suit] next steps in clarifying scoping terminolo… Michael Richardson
- Re: [Suit] next steps in clarifying scoping termi… Dick Brooks
- Re: [Suit] next steps in clarifying scoping termi… Michael Richardson
- Re: [Suit] next steps in clarifying scoping termi… Carsten Bormann
- Re: [Suit] next steps in clarifying scoping termi… Brendan Moran
- Re: [Suit] next steps in clarifying scoping termi… Brendan Moran
- Re: [Suit] next steps in clarifying scoping termi… Michael Richardson