[netconf] Roman Danyliw's Discuss on draft-ietf-netconf-tls-client-server-39: (with DISCUSS and COMMENT)

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

Roman Danyliw has entered the following ballot position for
draft-ietf-netconf-tls-client-server-39: 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-tls-client-server/



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

As mentioned in the ssh-client-server draft, I struggle to understand when it
is assumed that the security considerations of the imported modules apply, and
when they will be surfaced as issues in the module that is using them.  With
that confusion in mind:

** Section 5.3 and 5.4
   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.

   Please be aware that this module uses the "key" and "private-key"
   nodes from the "ietf-crypto-types" module
   [I-D.ietf-netconf-crypto-types], where said nodes have the NACM
   extension "default-deny-all" set, thus preventing unrestricted read-
   access to the cleartext key values.

It is difficult for me to reconcile these two paragraphs.  The first says there
is nothing read sensitive in this YANG module.  The second paragraph helpfully
reminds us there are potentially sensitive private keys in the module. 
Additionally, from an OPSEC perspective, knowing which client/EE certificates
is held by a device might reveal information useful to an attacker.

Section 5.4 has similar language.


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

Thank you to Barry Leiba for the SECDIR review.

** Section 5.*
     The protocol-accessible read-only node for the algorithms supported
     by a server is mildly sensitive

What is meant by “mildly sensitive”?