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

Hi Roman,

This email shows up in my Inbox as unread, yet it regards the same two issues that I replied to in a separate email thread earlier today.

I am going to assume that my email earlier today will be used to chase these comments to ground, and thus there is no need to reply to these comments again.

Please let me know if there is a misunderstanding.

Thanks,
Kent

> On Feb 6, 2024, at 4:31 PM, Roman Danyliw via Datatracker <noreply@ietf.org> wrote:
> 
> 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?
> 
> 
> 
> _______________________________________________
> netconf mailing list
> netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf