Hi Eliot,
The only thing that I think that we need to tweak is the security section,
where I think that we need to be more explicit that this module is not designed
to be used by NETCONF/RESTCONF specifically to exempt you for needing regular
YANG security considerations template text (which you don't have).
Possibly, something like this:
OLD:
This document describes a schema for discovering the location of
information relating to software transparency, and does not specify
the access model for the information itself.
NEW:
This document describes a schema for discovering the location of
information relating to software transparency, and does not specify
the access model for the information itself. In particular, the YANG
module specified in this document is not intended to be accessed via
regular network management protocols, such as the NETCONF
[RFC6241] or RESTCONF [RFC8040], and hence the regular security
considerations for such usage are not considered here.
I also think that this paragraph can probably just be deleted, since there are
no paths listed (and it also talks about edit-config, a NETCONF operation):
There are a number of data nodes defined in this YANG module that are
writable/creatable/deletable (i.e., config true, which is the
default). Write operations (e.g., edit-config) to these data nodes
without proper protection can have a negative effect on network
operations. These are the subtrees and data nodes and their
sensitivity/vulnerability:
Again, I'm not sure that we should have this paragraph since it doesn't list
any paths, and also implies that NETCONF operations may be used:
Some readable data nodes in this YANG module may be considered
sensitive or vulnerable in some network environments. It is thus
important to control read access (e.g., via get, get-config, or
notification) to these data nodes.
Regards,
Rob
> >> 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].
> -----Original Message-----
> From: Eliot Lear <l...@lear.ch>
> Sent: 12 January 2023 14:24
> To: Rob Wilton (rwilton) <rwil...@cisco.com>; draft-ietf-opsawg-sbom-
> access....@ietf.org
> Cc: opsawg@ietf.org
> Subject: Re: [OPSAWG] AD review of draft-ietf-opsawg-sbom-access-12
>
> Ok, this is now posted as -13.
>
> On 06.01.23 16:28, Eliot Lear wrote:
> > Hi Rob,
> >
> > On 19.12.22 17:25, Rob Wilton (rwilton) wrote:
> >> 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).
> >
> > Sorry- that's an artifact of an earlier rev. Corrected.
> >
> >
> >>
> >>
> >> (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.
> >
> > I think this needs more work. To begin with, on the whole, people
> > will probably NOT use NETCONF or RESTCONF for this information. It's
> > possible, but not likely. So the beginning text is really not
> > appropriate. What I propose to to replace the NETCONF/RESCONF gunk
> > with the following:
> >
> >
> > This document describes a schema for discovering the location of
> > information relating to software transparency, and does not specify
> > the access model for the information itself. We describe below
> > protections relating to both discovery and some advice on
> > protecting
> > the underlying SBOM/vulnerability information.
[Rob Wilton (rwilton)]
> >
> >
> >>
> >>
> >> 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?
> >
> > It is. This refers to software transparency of components; thus what
> > the inventory is and what associated vulnerabilities are.
[Rob Wilton (rwilton)]
Okay.
> >
> >
> >>
> >>
> >> (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?
> >
> > Not in this work.
[Rob Wilton (rwilton)]
Okay.
> >
> >
> >>
> >>
> >> (5) p 4, sec 2. The well-known transparency endpoint set
> >>
> >> Two well known endpoint is defined:
> >>
> >> "Two" => "a", and well known => well-known?
> >
> > yes
> >
> >
> >>
> >>
> >> (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.
> >
> > Ok, how about this:
> >
> >
> > The model specifies both encrypted and unencrypted means to retrieve
> > information. This is a matter of pragmatism. Unencrypted
> > communications allow for manipulation of information being retrieved.
> > Therefore, it is RECOMMENDED that implementations offer a means to
> > configure endpoints so that they may make use of TLS or DTLS.
[Rob Wilton (rwilton)]
Fine with me. I'll leave it to the SEC area and ADs to decide if it is
sufficient.
> >
> >
> >
> >>
> >> (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?
> >
> >
> > Ok.
> >
> >
> >>
> >>
> >> (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)?
> >
> > Ok, added pattern '((coaps?)|(https?)):.*';
[Rob Wilton (rwilton)]
Looks good, thanks.
> >
> >
> >
> >>
> >> (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.
> >
> >
> > Done and done.
> >
> >
> >>
> >> (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?
> >
> > So are the other two. Let's let this one pass.
[Rob Wilton (rwilton)]
Okay, ;-)
> >
> >
> >>
> >>
> >> (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"?
> >
> > Done.
> >
> >
> >>
> >>
> >> (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).
> > Yes.
> >>
> >> ii. Should you not also have the same pattern statement that you also
> >> have for sbom-contact-uri?
> >
> > And yes.
> >
> >
> >>
> >> (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?
> > Yes. I will look to see this is a bug in my code.
[Rob Wilton (rwilton)]
Okay. I can see that 'ol' is removed from the example in the latest draft.
> >>
> >>
> >> (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".
> >>
> > Thanks for the atch
> >
> >
> >>
> >> 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 ..."
> >
> > Change to and to.
> >
> >
> >>
> >> (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?
> >>
> > Done and done.
> >
> >
> >> 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"
> > no
> >>
> >> 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"
> >
> > OBE.
> >
> >
> >>
> >> 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"
> > Ok
> >>
> >> 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"
> >
> > Bad edit. Fixed.
> >
> >
> >>
> >> Section: 6, draft text:
> >> federations of SBOM servers.
> >> Warning: This sentence does not start with an uppercase letter.
> >> Suggested change: "Federations"
> >
> > OBE.
> >
> >
> > Thanks!
> >
> > Eliot
> >
> >
> > _______________________________________________
> > OPSAWG mailing list
> > OPSAWG@ietf.org
> > https://www.ietf.org/mailman/listinfo/opsawg
> >
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
