Re: [OPSAWG] AD review of draft-ietf-opsawg-sbom-access-12
Hi Eliot, I see that mostly the security section is really about the sensitivity of the data fields in the data model, and also whether those fields have default deny-all NACM rules. How the data is accessed shouldn’t really matter so much since the same principles should apply. However, generally for YANG documents, framing that in the context of NETCONF/RESTCONF and NACM makes sense, at least to me :-) Regards, Rob From: Eliot Lear Sent: 27 February 2023 14:29 To: Rob Wilton (rwilton) ; draft-ietf-opsawg-sbom-access@ietf.org Cc: opsawg@ietf.org Subject: Re: [OPSAWG] AD review of draft-ietf-opsawg-sbom-access-12 I do think it's worth having a broader conversation about security considerations of YANG models, because the very idea that YANG is tied to NETCONF/RESTCONF means that either we end up in these sorts of silly situations in which the security considerations are largely inapplicable OR we end up having to reinvent/tranliterate models into other languages. Eliot On 27.02.23 14:48, Rob Wilton (rwilton) wrote: Hi Eliot, Thanks. I’ll initiate IETF LC on -14. It is possible that the “necessarily” may mean that the SEC ADs will want more of the regular YANG security considerations to be included, but we can cross that bridge during the IESG review, if needed. Regards, Rob From: Eliot Lear <mailto:l...@lear.ch> Sent: 27 February 2023 13:25 To: Rob Wilton (rwilton) <mailto:rwil...@cisco.com>; draft-ietf-opsawg-sbom-access@ietf.org<mailto:draft-ietf-opsawg-sbom-access@ietf.org> Cc: opsawg@ietf.org<mailto:opsawg@ietf.org> Subject: Re: [OPSAWG] AD review of draft-ietf-opsawg-sbom-access-12 Rob: I think it's appropriate to accept all of your proposed changes with one caveat: On 07.02.23 14:50, Rob Wilton (rwilton) wrote: 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 necessarily 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. That is, if someone wants to play around with this with NETCONF/RESTCONF, there's nothing there to stop them. Your point about intent is key, tho. Eliot ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] AD review of draft-ietf-opsawg-sbom-access-12
I do think it's worth having a broader conversation about security considerations of YANG models, because the very idea that YANG is tied to NETCONF/RESTCONF means that either we end up in these sorts of silly situations in which the security considerations are largely inapplicable *OR* we end up having to reinvent/tranliterate models into other languages. Eliot On 27.02.23 14:48, Rob Wilton (rwilton) wrote: Hi Eliot, Thanks. I’ll initiate IETF LC on -14. It is possible that the “necessarily” may mean that the SEC ADs will want more of the regular YANG security considerations to be included, but we can cross that bridge during the IESG review, if needed. Regards, Rob *From:*Eliot Lear *Sent:* 27 February 2023 13:25 *To:* Rob Wilton (rwilton) ; draft-ietf-opsawg-sbom-access@ietf.org *Cc:* opsawg@ietf.org *Subject:* Re: [OPSAWG] AD review of draft-ietf-opsawg-sbom-access-12 Rob: I think it's appropriate to accept all of your proposed changes with one caveat: On 07.02.23 14:50, Rob Wilton (rwilton) wrote: 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*necessarily* 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. That is, if someone wants to play around with this with NETCONF/RESTCONF, there's nothing there to stop them. Your point about intent is key, tho. Eliot ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] AD review of draft-ietf-opsawg-sbom-access-12
Hi Eliot, Thanks. I’ll initiate IETF LC on -14. It is possible that the “necessarily” may mean that the SEC ADs will want more of the regular YANG security considerations to be included, but we can cross that bridge during the IESG review, if needed. Regards, Rob From: Eliot Lear Sent: 27 February 2023 13:25 To: Rob Wilton (rwilton) ; draft-ietf-opsawg-sbom-access@ietf.org Cc: opsawg@ietf.org Subject: Re: [OPSAWG] AD review of draft-ietf-opsawg-sbom-access-12 Rob: I think it's appropriate to accept all of your proposed changes with one caveat: On 07.02.23 14:50, Rob Wilton (rwilton) wrote: 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 necessarily 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. That is, if someone wants to play around with this with NETCONF/RESTCONF, there's nothing there to stop them. Your point about intent is key, tho. Eliot ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] AD review of draft-ietf-opsawg-sbom-access-12
Rob: I think it's appropriate to accept all of your proposed changes with one caveat: On 07.02.23 14:50, Rob Wilton (rwilton) wrote: 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*necessarily* 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. That is, if someone wants to play around with this with NETCONF/RESTCONF, there's nothing there to stop them. Your point about intent is key, tho. Eliot ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] AD review of draft-ietf-opsawg-sbom-access-12
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 > Sent: 12 January 2023 14:24 > To: Rob Wilton (rwilton) ; 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 p
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.
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.
(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.
(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.
(7) p 7, sec 4. T
Re: [OPSAWG] AD review of draft-ietf-opsawg-sbom-access-12
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.
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.
(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.
(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.
(7) p 7, sec 4. The mud-sbom augmentation to the MUD YANG model
identity coaps {
[OPSAWG] AD review of draft-ietf-opsawg-sbom-access-12
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
