Subject: Re: [OPSAWG] some comments and thoughts on mud-sbom and sbom-type

From: Eliot Lear <[email-masked]>
Date: Tue, 18 Aug 2020 15:18:42 +0200

Hi Michael

> On 28 Jul 2020, at 17:22, Michael Richardson <[email-masked]> wrote:
> 
> Signed PGP part
> 
> Hi Eliot,
> 
> 0) PLEASE ADOPT THIS DOCUMENT.
>   (Also I have some other MUD related documents which await the chairs' attention)

+1, but let’s not expect a rush on approval.  Lots of work needed.

> 
> As I said in the meeting, I don't really understand sbom-local.
> I asked this online, but let me repeat.
> 
> 1) It seems that just putting coaps:///.well-known/sbom in the URI might work as well.
>   If necessary, then maybe: coaps://127.0.0.1/.well-known/sbom or https://[::1]/.well-known/sbom
>   CoAP does have a Content-Type for returned content, but it is true that
>   there isn't as much negotiation by default in the form of Accept:

I don’t think /// is a real construct.  There are two issues.  We don’t know the hostname and we don’t know the scheme.  But the MUD manager does know the hostname, and we need to be provided the scheme.  There is no convention for ME without a pre-existing context.  That might be something to work on, but it would hav to happen in coordination with the COAP and HTTP working groups, and I don’t know how big a job it would be.  Thus what’s there.

> 
> 2) I think that I'm interested in what the format of the sbom is than I am
>   about how to get it.

Well, you have your choice of at least three different classes and multiple encoding variants.  Nice thing about standards, eh?

> 
> 3) I think that, in general, that the SBOMs will seldom be hosted on a
>   constrained device that is capable of being described by MUD.
>   {that is, devices that can self-host an SBOM, will tend to be servers,
>   desktops,    etc. that are not easily described by MUD.

Perhaps.  I can’t say.  We’re going to need some operational experience.  There are a number of use cases in the IoT field where you plug in different components that require different software loads.  One aspect of SBOM, by the way, that hasn’t been explored is the difference between software being installed and the code being placed in service.  Particularly drivers and supporting user-level software.

> 
>   So I am not convinced that this is use case is reasonable.
> 
> Alternative paths:
> 
> a) There is also a draft,  draft-moran-suit-mud-00
>       Strong Assertions of IoT Network Access Requirements
> 
>   which would provide a MUD URL as part of a Software Update process.
>   It will be at secdispatch on Thursday.

How did this go?

> 
> 
> b) There is a draft:       draft-birkholz-rats-mud-00
>   which uses a MUD file to point to a list of appraisal evidence (ras-uris),
>   a list of RIM CoSWID (SBOM!), and edt-uri (endorsements of Roots of Trust)

Indeed.

> 
> These are *not* mutually exclusive, and we should have multiple paths for
> different ecosystems.
> 

Righto.

Eliot

---

From: Henk Birkholz <[email-masked]>
Date: Tue, 18 Aug 2020 15:53:28 +0200

Hi Eliot,

replying to a single item below.

> Perhaps.  I can’t say.  We’re going to need some operational experience.  There are a number of use cases in the IoT field where you plug in different components that require different software loa…

"code being placed in service"
Does that refer to a software creation process or a packaging process, 
or both? (or... something entirely different that I did not get)

Viele Grüße,

Henk

---

From: Eliot Lear <[email-masked]>
Date: Tue, 18 Aug 2020 15:55:25 +0200

> Does that refer to a software creation process or a packaging process, or both? (or... something entirely different that I did not get)

Neither.  The code may be on the box already, but at all not invoked.

Regards,

Eliot

---

From: Henk Birkholz <[email-masked]>
Date: Tue, 18 Aug 2020 16:02:00 +0200

Just to be really sure: invoke implies executables and not code 
fragments, yes? If you mean executables that would be the SAM scope of 
SWID then, I think.

Why do you think that this has not been explored? I was under the 
impression that this is currently being covered in the SBOM WGs out there.

---

From: Eliot Lear <[email-masked]>
Date: Tue, 18 Aug 2020 16:33:38 +0200

> On 18 Aug 2020, at 16:02, Henk Birkholz <[email-masked]> wrote:
> 
> Just to be really sure: invoke implies executables and not code fragments, yes? If you mean executables that would be the SAM scope of SWID then, I think.

At this level I was thinking of both.  So for instance, a loadable object such as a driver, or the supporting software that the driver might then invoke at user level (or visa versa).

> 
> Why do you think that this has not been explored? I was under the impression that this is currently being covered in the SBOM WGs out there.

If it has, I am not aware, and that may be my own ignorance.  I do know that they fully understand dependencies and some of those relationships can be quite rich between the systems (SWF gets down to a source file/function), and whether the software is present.  But whether it’s invoked via a fn() or execv() and the like?  That I haven’t seen.

Eliot

---

From: Michael Richardson <[email-masked]>
Date: Sun, 23 Aug 2020 17:53:14 -0400

>> Perhaps.  I can’t say.  We’re going to need some operational
    >>experience.  There are a number of use cases in the IoT field where you
    >>plug in different components that require different software loads.  One
    >>aspect of SBOM, by the way, that hasn’t been explored is the difference
    >>between software being installed and the code being placed in service.
    >>Particularly drivers and supporting user-level software.

    > Does that refer to a software creation process or a packaging process, or
    > both? (or... something entirely different that I did not get)

to recap:

There are multiple ways to get:
  1) a MUD URL
  2) an SBOM URL

For MUD, one can get it from: IDevID or DHCP/LLDP.
To this, we are talking about adding: via SUIT manifest.

For SBOM URL, the ways I know of, at present are:
    a) this proposed MUD->SBOM
    b) a possible SUIT->SBOM
    c) something like CHARRA via EAT.

The path via IDevID(MUD URL), MUD(SBOM) involves at least one signature from
the manufacturer, probably two if the MUD is signed.
But, no assurance that the device is actually running that version of the
software, since IDevID are hard to update.  But, that's 100x better than what
we have now!

The path via SUIT->SBOM involves a single signature from the manufacturer,
but again, no assurance that the firmware provided to the device is what is
currently running.

The path via DHCP for the MUD URL, could result in a MUD file that is not
signed (could be fake), and could result in a pointer to an SBOM that is
bogus.

The best would seem to be have a SBOM come from Evidence produced by
CHARRA.  It would be signed by the IDevID (or other Attestation key).
This probably means that the device is running the correct firmware.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Sun, 23 Aug 2020 17:57:40 -0400

> I don’t think /// is a real construct.  There are two issues.  We don’t
    > know the hostname and we don’t know the scheme.  But the MUD manager
    > does know the hostname, and we need to be provided the scheme.  There
    > is no convention for ME without a pre-existing context.  That might be
    > something to work on, but it would hav to happen in coordination with
    > the COAP and HTTP working groups, and I don’t know how big a job it
    > would be.  Thus what’s there.

okay, good point.
I think that the self-hosted SBOM is relatively unlikely.
I just don't think we should complicate the system too much to accomodate it.

    > Well, you have your choice of at least three different classes and
    > multiple encoding variants.  Nice thing about standards, eh?

:-)

    > plug in different components that require different software loads.
    > One aspect of SBOM, by the way, that hasn’t been explored is the
    > difference between software being installed and the code being placed
    > in service.  Particularly drivers and supporting user-level software.

I completely agree: same actuator platform connector to different kinds of "valves"
No reason why a variable gas regulator should be significantly different than
a variable water regulator.
Except for the physical mechanism they are attached to, and therefore some
parameters about how fast/slow to move things.  Why keep two kinds of spares?

    > How did this go?

It has been sent back to SUIT.