[netconf] Roman Danyliw's Discuss on draft-ietf-netconf-trust-anchors-23: (with DISCUSS and COMMENT)

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

Roman Danyliw has entered the following ballot position for
draft-ietf-netconf-trust-anchors-23: Discuss

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/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

** Section 5.1
   In order to satisfy the expectations of a "truststore", it is
   RECOMMENDED that implementations ensure that the truststore contents
   are protected from unauthorized modifications when at rest.

Similar feedback to draft-ietf-netconf-keystore.  If this recommendation is NOT
followed how would this expectation be satisfied?  Shouldn't ensuring that the
truststore is protected be mandatory?


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

Thank you to Yoav Nir for the SECDIR review.

** Clarifying that certificates are actually certificate chains in the node
descriptions. YANG.  typedef central-certificate-ref

       description
         "This typedef defines a reference to a specific certificate
          in a certificate bag in the central truststore. This typedef
          requires that there exist a sibling 'leaf' node called
          'certificate-bag' that SHOULD have the typedef
          'central-certificate-bag-ref'.";

YANG.  list certificate
               description
                 "An arbitrary name for this certificate.";

** YANG.  Typo. s/inlucging/including/

** 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 3.
   Built-in bags of trust anchors and/or specific trust anchors, that
   are referenced by configuration (e.g., a "leafref"), MUST be present
   in a datastore in order for the datastore to be valid.

   Built-in bags and/or their trust anchors MAY be copied into other
   parts of the configuration but, by doing so, they lose their
   association to the built-in entries and any assurances afforded by
   knowing they are/were built-in.

As with netconf-keystore, I’m having trouble with the guidance for built-in
keys, more specifically, the guidance around a data-store.

-- If something is “built-in”, isn’t it by definition in some kind of datastore
already.  Are there now multiple data stores?

-- What does “copying” into a different part of the configuration mean?  Aren’t
we talking about an XML file?  Does this imply keys are moved from one
data-store (the built-in?) to another one (e.g., a OS or application specific
one)?

** 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?