[netconf] Roman Danyliw's No Objection on draft-ietf-netconf-trust-anchors-24: (with COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw has entered the following ballot position for
draft-ietf-netconf-trust-anchors-24: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netconf-trust-anchors/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you to Yoav Nir for the SECDIR review.

Thanks for addressing my DISCUSS and part of my COMMENT.

** YANG.  list certificate-bag
             "A bag of certificates.  Each bag of certificates SHOULD
              be for a specific purpose.  For instance, one bag could
              be used to authenticate a specific set of servers, while
              another could be used to authenticate a specific set of
              clients.";

Since normative language is used here, can additional guidance be provided on
qualifying “specific purpose”.  For example, can one put different applications
for the same server in the same bag?  What is the consequence of incorrectly
binning the certificate chains? More generally, I’m wondering about the
significance of where certificates are binned.  Because of natural language
describing the purpose of these bags, I don’t see an obvious, interoperable,
general purpose way to automatically parse this structure to know which
certificate to use for a server beyond checking subjectAltNames in the
certificate against a domain name (which precludes the need to even organize
these certificates into bins beyond readability).

** Section 4.3
   None of the readable data nodes defined in this YANG module are
   considered sensitive or vulnerable in network environments.  The NACM
   "default-deny-all" extension has not been set for any data nodes
   defined in this module.

Doesn’t read-access to this module provide insight into which other
resources/applications/servers this particular server communicates with by
virtue of having their end-entity certificates or SSH keys?  Wouldn’t this
provide an attacker insight into potential targeting?  or business
relationships?