[OPSAWG] AD review of draft-ietf-opsawg-sbom-access-12

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Eliot, Scott,

Thanks for this document.  Here is my AD review for draft-ietf-opsawg-sbom-access-12.


Moderate level comments:

(1) p 3, sec 1.  Introduction

   To enable application-layer discovery, this memo defines a well-known
   URI [RFC8615].  Management or orchestration tools can query this
   well-known URI to retrieve a system's SBOM or vulnerability
   information.  Further queries may be necessary based on the content
   and structure of the response.

It looks like the .wellknown URI can only be used to retrieve SBOM information and not vulnerability information (unless I am missing something).


(2) p 15, sec 6.  Security Considerations

   The YANG module specified in this document defines a schema for data
   that is designed to be accessed via network management protocols such
   as NETCONF [RFC6241] or RESTCONF [RFC8040].  The lowest NETCONF layer
   is the secure transport layer, and the mandatory-to-implement secure
   transport is Secure Shell (SSH) [RFC6242].  The lowest RESTCONF layer
   is HTTPS, and the mandatory-to-implement secure transport is TLS
   [RFC8446].

This text looks to be inconsistent with earlier parts of the document, specifically, I didn't think that the intent was to fetch this information using NETCONF or RESTCONF, but the early part of this document states that it contains groupings, which presumably could be used in any YANG model, and hence security considerations would apply.

I would suggest that you split the security considerations into two separate sub-sections:

i. The security considerations as this document applies to documenting SBOMs as part of the MUD file.  Which I think is most of the text that you have below.  As per above I think that it is this section that should be updated to comment on the use of the insecure version of http and coap.

ii. A separate sub-section that only applies if the groupings are being used in regular YANG modules accessed via NETCONF/RESTCONF and that follows the standard YANG security template.



Minor level comments:

(3) p 0, sec 

   Discovering and Retrieving Software Transparency and Vulnerability
                              Information
                    draft-ietf-opsawg-sbom-access-12

It wasn't obvious to me why this is called "transparency", is this is a standard term of art for SBOMs?


(4) p 4, sec 1.1.  How This Information Is Retrieved

   Note that vulnerability and SBOM information is likely to change at
   different rates.  MUD's cache-validity node provides a way for
   manufacturers to control how often tooling should check for those
   changes through the cache-validity node.

Just for my understanding: Is there any mechanism for clients to register for notification of changes rather than polling?


(5) p 4, sec 2.  The well-known transparency endpoint set

   Two well known endpoint is defined:

"Two" => "a", and well known => well-known?


(6) p 7, sec 4.  The mud-sbom augmentation to the MUD YANG model

     identity http {
       base mudtx:local-type;
       description
         "Use http (insecure) to retrieve SBOM information.  This
           method is NOT RECOMMENDED, but may be unavoidable for
           certain classes of deployment, where TLS has not or
           cannot be implemented";
     }

I'm okay with this and coap (from a pragmatism POV).  But I think that the security section should talk about this: I.e., emphasize that secure versions MUST be used in preference, if available, and highlight the risks if insecure protocols are used.


(7) p 7, sec 4.  The mud-sbom augmentation to the MUD YANG model

     identity coaps {
       base mudtx:local-type;
       description
         "Use COAPS (secure) to retrieve SBOM";
     }

Possibly add YANG reference statements to point to the latest http, https, coap, and coaps specifications?


(8) p 8, sec 4.  The mud-sbom augmentation to the MUD YANG model

         choice sbom-retrieval-method {
           description
             "How to find SBOM information";
           case cloud {
             list sboms {
               key "version-info";
               description
                 "A list of SBOMs tied to different software
                  or hardware versions.";
               leaf version-info {
                 type string;
                 description
                   "The version to which this SBOM refers.";
               }
               leaf sbom-url {
                 type inet:uri;
                 description
                   "A statically located URL.";
               }

Should any URI be allowed here, or should it be pattern restricted to http(s) or coap(s)?


(9) p 8, sec 4.  The mud-sbom augmentation to the MUD YANG model

         leaf archive-list {
           type inet:uri;
           description
             "This URI returns a JSON list of URLs that consist of
                     SBOMs that were previously published for this
                     device.  Publication dates can found inside
                     the SBOMs.";

i.  Why not "sbom-archive-list"?

ii. Please also reformat the description.


(10) p 8, sec 4.  The mud-sbom augmentation to the MUD YANG model

         }
         choice vuln-retrieval-method {
           description
             "How to find vulnerability information";
           case cloud {

Is cloud a slightly colloquial term?  Would 'remote' or 'online' be more general?


(11) p 8, sec 4.  The mud-sbom augmentation to the MUD YANG model

             leaf vuln-url {
               type inet:uri;
               description
                 "A statically located URL.";

Perhaps "A statically located URL that references the vulnerability information"?


(12) p 9, sec 4.  The mud-sbom augmentation to the MUD YANG model

             }
           }
           case vuln-contact-info {
             leaf contact-uri {
               type inet:uri;
               description
                 "This MUST be either a tel, http, https, or
                  mailto uri schema that customers can use to
                  contact someone for vulnerability information.";

i. Should this be "vuln-conctact-uri" (since the case statement doesn't appear in the instance data).  The alternative solution would be to introduce "sbom" and "vuln" containers which would then force those containing identifiers into the instance data.

ii. Should you not also have the same pattern statement that you also have for sbom-contact-uri?


(13) p 10, sec 5.1.  Without ACLS

   This first MUD file demonstrates how to get SBOM and vulnerability
   information without ACLs.
  {
    "ietf-mud:mud": {
      "mud-version": 1,
      "extensions": [
        "ol",
        "transparency"
      ],
      "ol": {
        "owners": [
          "Copyright (c) Example, Inc. 2022. All Rights Reserved"
        ],
        "spdx-tag": "0BSD"
      },

Where is the "ol" extension defined.  I would have thought that the top node would need a prefix and name?


(14) p 16, sec 6.  Security Considerations

   SBOMs provide an inventory of software.  If software is available to
   an attacker, the attacker may well already be able to derive this
   very same software inventory.  When this information resides on the
   endpoint itself, the endpoint SHOULD NOT provide unrestricted access
   by default.  Other servers that offer the data MAY restrict access to
   SBOM information using appropriate authorization semantics within
   HTTP.  One way to do this would be to issue a certificate to the
   client for this purpose after a registration process has taken place.
   Another approach would involve the use of OAUTH in combination with a
   In particular, if a system attempts to retrieve an SBOM via HTTP and
   the client is not authorized, the server MUST produce an appropriate
   error, with instructions on how to register a particular client.
   federations of SBOM servers.

Editing error?  "with a ... " and "federations of SBOM servers".



Nit level comments:

(15) p 0, sec 

   To improve cybersecurity posture, automation is necessary to locate
   what software is running on a device, whether that software has known
   vulnerabilities, and what, if any recommendations suppliers may have.
   This memo extends the MUD YANG model to provide the locations of
   software bills of materials and to vulnerability information.

I find the last sentence hard to read, e.g., the "to vulnerability ..."


(16) p 7, sec 4.  The mud-sbom augmentation to the MUD YANG model

     grouping transparency-extension {
       description
         "This grouping provides a means to describe the location of
          software bills of material and vulnerability descriptions.";
       container transparency {
         description
           "container of methods to get an SBOM.";

Please capitalize the first letter.  Also, this container holds data other than just how to get SBOMs, should the description reflect that?


Other grammar warnings generated by an automated tool (some may already be flagged above):

Grammar Warnings:
Section: 1, draft text:
- on devices themselves - on a web site (e.g., via URI) - through some form of out-of-band contact with the supplier. 
Warning:  Nowadays it's more common to write this as one word.
Suggested change:  "website"

Section: 2, draft text:
Two well known endpoint is defined:
Warning:  Possible agreement error. The noun 'endpoint' seems to be countable, so consider using: endpoints.
Suggested change:  "endpoints"

Section: 6, draft text:
Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. 
Warning:  If the text is a generality, 'of the' is not necessary.
Suggested change:  "Some"

Section: 6, draft text:
Another approach would involve the use of OAUTH in combination with a In particular, if a system attempts to retrieve an SBOM via HTTP and the client is not authorized, the server MUST produce an appropriate error, with instructions on how to register a particular client. 
Warning:  Use an instead of 'a' if the following word starts with a vowel sound, e.g. 'an article', 'an hour'
Suggested change:  "an"

Section: 6, draft text:
federations of SBOM servers.
Warning:  This sentence does not start with an uppercase letter.
Suggested change:  "Federations"

Regards,
Rob