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

From: Michael Richardson <[email-masked]>
Date: Tue, 09 Jun 2020 12:13:33 -0400

{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 <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Dick Brooks" <[email-masked]>
Date: Tue, 9 Jun 2020 12:36:20 -0400

+1

Thanks,

Dick Brooks

Never trust software, always verify and report! T
http://www.reliableenergyanalytics.com
Email: [email-masked]
Tel: +1 978-696-1788

-----Original Message-----
From: Suit <[email-masked]> On Behalf Of Michael Richardson
Sent: Tuesday, June 09, 2020 12:14 PM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: [Suit] next steps in clarifying scoping terminology for SUIT,
CoSWID, MUD and SBOM

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.

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.

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.

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 <[email-masked]>, Sandelman Software Works  -=
IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Tue, 09 Jun 2020 13:41:04 -0400

{Annoyingly, the LWIG wg's ML is [email-masked].
We gotta stop own-goals like this.
My appologies for repeating myself}

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 9 Jun 2020 21:06:21 +0200

Hi Michael,

> On 2020-06-09, at 18:13, Michael Richardson <[email-masked]> wrote:
> 
> […] smartphones do not fit into RFC7228, and yet they are not "unconstrained"
> 

There is activity on a 7228 bis.

Would

https://tools.ietf.org/html/draft-bormann-lwig-7228bis-06#table-1

have helped you?

This has a number of experimental classes above 2; both in the M Group (microcontrollers) and the J Group (general purpose computers — pun only accessible to people who know how Jeeps got their name).

Note that Sections 3.1..3.3 have more experimental categories; not sure these are useful for what you are trying to do.

Grüße, Carsten

---

From: Brendan Moran <[email-masked]>
Date: Thu, 11 Jun 2020 13:13:26 +0000

My reply appears to have fallen prey to the same problem as Michael’s message.

Best Regards,
Brendan

> On 11 Jun 2020, at 14:05, Brendan Moran <[email-masked]> wrote:
>
> I think there may be some misconceptions about SUIT here.
>
> The SUIT charter says:
>
>> 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.
>
> 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.
>
> Please could you explain what the problem you see is that would make suit inappropriate for smartphone apps or many-component systems.
>
> Best Regards,
> Brendan
>
>> On 9 Jun 2020, at 17:13, Michael Richardson <[email-masked]> wrote:
>>
>>
>> _______________________________________________
>> Suit mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/suit
>

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Brendan Moran <[email-masked]>
Date: Thu, 11 Jun 2020 13:05:38 +0000

Best Regards,
Brendan

---

From: Michael Richardson <[email-masked]>
Date: Thu, 11 Jun 2020 18:17:24 -0400

{Please no negative aspersions were intended!}

    > 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.

    > 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
    bootloaders

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.