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

Michael Richardson <> Thu, 11 June 2020 22:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 117763A07DB; Thu, 11 Jun 2020 15:17:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FR3S0ryFsNKj; Thu, 11 Jun 2020 15:17:28 -0700 (PDT)
Received: from ( [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 (Postfix) with ESMTPS id 76D4C3A07E7; Thu, 11 Jun 2020 15:17:28 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1CE893898D; Thu, 11 Jun 2020 18:14:57 -0400 (EDT)
Received: from ([]) by localhost (localhost []) (amavisd-new, port 10024) with LMTP id 3rTF-Ok5kwy6; Thu, 11 Jun 2020 18:14:54 -0400 (EDT)
Received: from ( [IPv6:2607:f0b0:f:2::247]) by (Postfix) with ESMTP id 310523898C; Thu, 11 Jun 2020 18:14:54 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id 6294B2A2; Thu, 11 Jun 2020 18:17:24 -0400 (EDT)
From: Michael Richardson <>
To: Brendan Moran <>, suit <>
cc:, "opsawg\" <>, sacm <>
In-Reply-To: <>
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: Thu, 11 Jun 2020 18:17:24 -0400
Message-ID: <11074.1591913844@localhost>
Archived-At: <>
Subject: Re: [Suit] next steps in clarifying scoping terminology for SUIT, CoSWID, MUD and SBOM
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: Thu, 11 Jun 2020 22:17:31 -0000

{Please no negative aspersions were intended!}

Brendan Moran <> wrote:
    > I think there may be some misconceptions about SUIT here.

So, let's distinguish what draft-ietf-suit-manifest-07 *CAN* do, from what
the *SUIT* *WG* needs to be able to defend.

So, we often articially limit applicability for solutions in order to be able to
get complete coverage, particularly when it comes to Security Considerations.

We then can come back, write a new applicability statement and extend usage.
It is my understanding that this is what the WG is doing.

    >> This group will focus on defining a firmware update solution (taking into
    >> account past learnings from RFC 4108 and other firmware update solutions) that
    >> will be usable on Class 1 (as defined in RFC 7228) devices, i.e., devices with
    >> ~10 KiB RAM and ~100 KiB flash. The solution may apply to more capable devices
    >> as well.

    > The suit manifest does, happily, apply to more capable devices. The
    > suit manifest is, in principle, being adopted in TEEP, which targets
    > more capable devices.

Yes, that's definitely true.  And quite reasonably the things which are
deployed into the secure enclaves managed by the TEEP Agent might look a lot
like "APPs", and I would not fault some marketing person who wanted to call
them "Trusted Apps" [Afterall, we more or less call them that in the TEEP
Intro, and then use the term TA from when on], but, there is a lot of
difference in the attack surface for a TEEP TA than for an Android APK due to
the number of linkages to other services in Android, the use of Dalvik VM
(and it's replacement whose name I've forgotten), down to the libc that it
uses and the kernel underneath.

    > Certainly, the design of suit was explicitly intended to target Class 1
    > devices, however I am not aware of any missing feature or any missing
    > functionality that would inherently restrict SUIT from being used for
    > many component, high capability systems.

    > I see no inherent problem with using suit manifests to deploy
    > smartphone apps, docker containers, VM images, linux packages, kernel
    > images, recovery partitions or bootloaders.

In SUIT we have stayed away from saying anything about the contents of the
blob.  It can be a compressed file system, Intel HEX code, or even tar.gz.
What I *think* that we agree is that there ought *not* be 1292 blobs,
each one a different *file*.  It wouldn't be wrong, and it probably would
work, but if it turned out it was O(n^2) [or O(2^n)!] in the number of blobs,
then that would be a concern, wouldn't it?  I haven't thought about this, nor
do I expect to, since I think n<10.

So, I did say *specifically* that I do expect to use SUIT for:
    docker containers
    VM images
    kernel images
    recovery partitions

I'm less sure that it should admit that it can be used for apps and linux
packages, because I'm very much certain that the Security Considerations for
some of this will overwhelm us, and overwhelm the readers.
In particular the dependancy relationship that often needs to be expressed
can be quite complex.  Can our MANIFEST be extended to support it? I'm
sure. Should we spend the time now?
No, because, I don't think those constituencies want to replace what they have now.

    > Please could you explain what the problem you see is that would make
    > suit inappropriate for smartphone apps or many-component systems.

I hope that I have explained myself.

Michael Richardson <>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-