Subject: [OPSAWG] 🔔 WG Adoption Call on draft-lear-opsawg-sbom-access-00

From: Henk Birkholz <[email-masked]>
Date: Mon, 4 Jan 2021 17:10:19 +0100

Dear OPSAWG members,

this starts a call for Working Group Adoption on 
https://tools.ietf.org/html/draft-lear-opsawg-sbom-access-00 ending on 
Monday, January 25.

As a reminder, this I-D describes different ways to acquire Software 
Bills of Material (SBOM) about distinguishable managed entities. The 
work was updated by the authors on October 13th and now elaborates on 
three ways SBOM can be found, including a MUD URI as one of the options.

Please reply with your support and especially any substantive comments 
you may have.

For the OPSAWG co-chairs,

Henk

---

From: tangtianqing <[email-masked]>
Date: Wed, 20 Jan 2021 12:34:13 +0000

Hi,

I’ve read this draft and I support the adoption. Besides that, I have some comments below:

1)

1.  Introduction
While MUD files may include signatures, it is not mandatory to check them, and there is not a clear way to connect the entity which signed the MUD file to the device itself. A malicious device does not need to make up a MUD file if there is already an available, and already trusted MUD file which it can use to impersonate the device.
 
Comment > I think not checking signatures will cause significant vulnerability, and I also find RFC8520 doesn’t mention whether it’s mandatory to check signatures. Therefore, I am confused that if there is any special purpose or consideration not to check signatures of MUD files.

2)

1.	Introduction 
One defense against this is to not trust MUD URLs which are different from the one that was placed in an IDevID. Or if the initial MUD URL was not taken from an IDevID, it could be trusted on first use.

Comment > What does "this" mean? Does it refer to the problem that a device is unable to verify if the MUD URL belongs to itself, or the method above that cannot connect the MUD file signer with the device itself?

Comment > If IDevID mechanism is applied, why other MUD URLs exist? Or is it better here to say “MUD controller shouldn’t trust other MUD URLs than the one placed in an IDevID”?

3)

2.1.2. Removing capabilities
In this case the old device will be performing unwanted connections,
and the MUD controller when be alerting the device owner that the
device is mis-behaving. This causes a false positive situation (see
[boycrieswolf]), leading to real security issues being ignored. This
is a serious issue as documented also in [boywolfinfosec], and
[falsemalware].

Comment > What does “real security issues” mean? Does it means that the device owner mistakenly judge that the device is not upgraded as misbehaving?

4）

2.1.3. Significant changes to protocols
[I-D.reddy-opsawg-mud-tls] suggests MUD definitions to allow examination of TLS protocol details. Such a profile may be very specific to the TLS library which is shipped in a device. Changes to the library (including bug fixes) may cause significant changes to the profile, requiring changes to the profile described in the MUD file. Such changes are likely neither forward nor backward compatible with other versions, and in place updates to MUD files are therefore not indicated.
 
Comment > In my understanding, I think version updates should take compatibility into consideration, even for bug fixes. So why do you think they are likely not compatible with other versions?
 
5)

3. Threat model for MUD URLs
Only the DHCP and LLDP MUD URL mechanisms are sufficiently close to the firmware version that they can be easily updated when the firmware is updated.

Comment > There is no need to limit this draft to DHCP and LLDP mechanisms.
Although the IDvID mechanism makes the MUD URL in the IDvID certificate unchangeable, it can be assumed that a new MUD URL is carried in the firmware when the device is updated. If the new MUD URL matches the rules defined in this draft, then it can be considered reasonable.

6)

3.2. Concerns about same-signer mechanism
It is possible to invent policy mechanisms that would link the EE certificate to a value that is in the MUD file.

Comment > What is the function of linking the EE certificate to a value that is in the MUD file? How can it solve the problems brought by pinning the CA certificate or pinning the EE certificate?

7)

5. Changes to RFC8520
MUD files contain a self-referential MUD-URL attribute that point to a MUD file located on the vendor’s web site.
.
Comment > This sentence may be mistaken as that the MUD-URL attribute in multiple MUD files points to the same MUD file. However, in fact, the MUD-URL attribute in a certain MUD file points to the MUD file itself.

8)

5. Changes to RFC8520
The URL found in the MUD-URL attribute is to be called the canonical 
MUD URL for the device.

Comment > How to understand the meaning of “canonical MUD URL”?

9)

5. Changes to RFC8520
The MUD-SIGNATURE attribute in the MUD file SHOULD be a relative URI (see [RFC3986] section 4.2) with the (hierarchical) base URL for this reference being the MUD-URL attribute.

Comment > Does this sentence mean that The MUD-SIGNATURE attribute in the MUD file includes base URI?
Comment > Does “base URL” here has the same meaning with “Base-URI” mentioned in the draft?

10)

5. Changes to RFC8520
Once the new MUD file is accepted, then it becomes the new "root" MUD file, and any subsequent updates must be relative to the MUD-URL in the new file.

Comment > I feel that it’s better to make this requirement normative here. Is it appropriate to use “MUST” or “SHOULD”?

11)
6. Privacy Considerations
The MUD URL contains sensitive model and even firmware revision numbers. Thus the MUD URL identifies the make, model and revision of a device.

Comment > It may be recommended that MUD URLs use a random character string instead of the plaintext information, because the plaintext information is easy to guess (i.e. “The MUD URL contains sensitive model…”)

12)

5. Changes to RFC8520
Subsequent MUD files are considered valid if:
* have the same initial Base-URI as the MUD-URL, but may have a different final part…

Comment > I suggest that describe “MUD URL”, “MUD-URL”, and “mud-url” in advance due to their different meanings.

13)

7. Security Considerations
…depend upon the MUD-manager either not checking signatures, or…

Comment > I suggest that replace “MUD-manager” with MUD controller for consistency.

Best wishes,
Tianqing Tang

> -----Original Message-----
> From: OPSAWG [mailto:[email-masked]] On Behalf Of Henk 
> Birkholz
> Sent: Tuesday, January 5, 2021 12:10 AM
> To: opsawg <[email-masked]>
> Subject: [OPSAWG] 🔔 WG Adoption Call on
> draft-lear-opsawg-sbom-access-00
> 
> Dear OPSAWG members,
> 
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

---

From: "Panwei (William)" <[email-masked]>
Date: Sun, 24 Jan 2021 14:14:05 +0000

I've read the draft and I support the adoption. In addition, I have the following comments:

1) 
1. Introduction
An application-layer management system retrieving an SBOM in order
to evaluate the posture of an application server of some form.
These application servers may themselves be containers or
hypervisors. Discovery of the topology of a server is beyond the
scope of this memo.

Comment> I know there are application-layer firewalls, but I don't think it's also appropriate to use "application-layer" to describe the management system. The management system manages the application server, but should not be specific to "application-layer".

Comment> For an application server which doesn't support MUD before, if it wants to advertise its SBOM info, it needs to send a MUD URL and the related MUD file contains a SBOM URL, why doesn't it just send a SBOM URL?

2)
1. Introduction
A network-layer management system retrieving an SBOM from an IoT
device as part of its ongoing lifecycle. Such devices may or may
not have interfaces available to query SBOM information.

Comment> I also suggest not using "network-layer" to describe the management system, but saying that the management system evaluates the network behavior of the IoT devices.

Comment> For disambiguation, in the last sentence, it's better to say "to be queried for SBOM information".

3)
1.3. Discussion points
Are there other retrieval mechanisms that need to be specified?

Comment> Can the SBOM info be directly stored/written in the MUD file?

4)
3. The mud-sbom augmentation to the MUD YANG model
In the description of "leaf-list sbom-local", it is said:
"The choice of sbom-local means that the SBOM resides at
a location indicated by an indicted scheme for the
device in question, at well known location
’/.well-known/sbom’. For example, if the MUD file
indicates that coaps is to be used and the host is
located at address 10.1.2.3, the SBOM could be retrieved
at ’coaps://10.1.2.3/.well-known/sbom’. N.B., coap and
http schemes are NOT RECOMMENDED.";

Comment> The leaf-list "sbom-local" only indicates the transport Protocol, how can the MUD controller know the host address?

5)
4. Examples
The first MUD file demonstrates how to get the SBOM
without ACLs, and the second has ACLs.

Comment> Here should be "The first three MUD files demonstrate ..., and the forth has ACLs."

6)
5. Security Considerations
Another risk is a skew in the SBOM listing and the actual software
inventory of a device/container. For example, a manufactuer may
update the SBOM on its server, but an individual device has not be
upgraded yet. This may result in an incorrect policy being applied
to a device. A unique mapping of a device’s firmware version and its
SBOM can minimize this risk.

Comment> Can we add the firmware version info in the MUD file? So that there will be the mapping of firmware version and SBOM.

Regards & Thanks!
Wei Pan

> As a reminder, this I-D describes different ways to acquire Software Bills of
> Material (SBOM) about distinguishable managed entities. The work was
> updated by the authors on October 13th and now elaborates on three ways
> SBOM can be found, including a MUD URI as one of the options.
>

---

From: Eliot Lear <[email-masked]>
Date: Sun, 24 Jan 2021 16:22:34 +0100

Hi Wei Pan,

Thanks for this excellent review.  Please see below.

> On 24 Jan 2021, at 15:14, Panwei (William) <[email-masked]> wrote:
> 

I think your concern is with the term “application server”.  If so, I agree with you, the intent here is not to address application layer matters, but at the layer below.  Perhaps we could reword this to be a bit more clear.

> Comment> For an application server which doesn't support MUD before, if it wants to advertise its SBOM info, it needs to send a MUD URL and the related MUD file contains a SBOM URL, why doesn't it…

Actually, the intent is to not require certain application servers to send any URL ;-). Rather, to have a well known URI prefix so that the SBOM can be discovered through a query.

> Comment> I also suggest not using "network-layer" to describe the management system, but saying that the management system evaluates the network behavior of the IoT devices.

I am happy to remove the word “network-layer”, but I would rather not get into behavioral evaluation, as these are two different functions.

> Comment> For disambiguation, in the last sentence, it's better to say "to be queried for SBOM information".

Ok.

> Comment> Can the SBOM info be directly stored/written in the MUD file?

Not in this design.  MUD is intended only for discovery, and is certainly not intended to be the only discovery mechanism.

> Comment> The leaf-list "sbom-local" only indicates the transport Protocol, how can the MUD controller know the host address?

This has to be known by the MUD Manager.  I think it’s a good idea to say a bit more about this, though, since that may not be the case for all previous MUD Managers.  Do you agree?

> Comment> Here should be "The first three MUD files demonstrate ..., and the forth has ACLs."

Yes indeed.

> Comment> Can we add the firmware version info in the MUD file? So that there will be the mapping of firmware version and SBOM.

Indeed that is available, but a caution: MUD files that are tied to X.509-based MUD-URLs won’t show latest and greatest firmware.  This draft actually could heal that deficiency - to a point.

Eliot

---

From: Henk Birkholz <[email-masked]>
Date: Tue, 26 Jan 2021 14:03:18 +0100

Dear OPSAWG members,

this email concludes the call for Working Group Adoption on 
https://tools.ietf.org/html/draft-lear-opsawg-sbom-access-00.

We received a reasonable number of positive replies, no objections, and 
various significant comments.

The chairs believe this I-D is ready for adoption and for the working 
group to work on.

Authors please rename the draft to be draft-ietf-opsawg-sbom-access-00, 
keeping the content as is, and resubmit.

Henk

---

From: Eliot Lear <[email-masked]>
Date: Tue, 26 Jan 2021 15:17:58 +0100

Hi Henk,

I’ve made a handful of changes in the source to address the comments of Wei Pan.  Would you mind if I post that and allow for the possibility that we will back them out if necessary (I think they are non-controversial).

Eliot

> On 26 Jan 2021, at 14:03, Henk Birkholz <[email-masked]> wrote:
> 
> Dear OPSAWG members,
> 
> this email concludes the call for Working Group Adoption on https://tools.ietf.org/html/draft-lear-opsawg-sbom-access-00.
> 
> We received a reasonable number of positive replies, no objections, and various significant comments.
> 
> The chairs believe this I-D is ready for adoption and for the working group to work on.
> 
> Authors please rename the draft to be draft-ietf-opsawg-sbom-access-00, keeping the content as is, and resubmit.
> 
> 
>> this starts a call for Working Group Adoption on https://tools.ietf.org/html/draft-lear-opsawg-sbom-access-00 ending on Monday, January 25.
>> As a reminder, this I-D describes different ways to acquire Software Bills of Material (SBOM) about distinguishable managed entities. The work was updated by the authors on October 13th and now elaborates on three ways SBOM can be found, including a MUD URI as one of the options.
>> Please reply with your support and especially any substantive comments you may have.

---

From: Henk Birkholz <[email-masked]>
Date: Tue, 26 Jan 2021 15:40:00 +0100

Hi Eliot,

if you don't mind, I'd prefer a simple rename for -00 followed by an -01 
that addresses the comments from Wei. Looking at Wei's input, I agree 
that the result should be rather non-controversial (and can be further 
addressed in the working group proceedings, if the need arises - I'll 
keep an eye out for that).

Viele Grüße,

Henk