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

[Kent Watsen <[e-mail]>]

Hi Roman,

Thank you for clearing your DISCUSS position.
See below for more.

Kent



> On Feb 6, 2024, at 4:29 PM, Roman Danyliw <[e-mail]> wrote:
> 
> Hi Kent!
>  
> Thanks for the revised -24.  I’ve cleared my DISCUSS position.  A bit more inline …
>  
> From: Kent Watsen <[e-mail] <mailto:[e-mail]>> 
> Sent: Wednesday, January 31, 2024 3:52 PM
> To: Roman Danyliw <[e-mail] <mailto:[e-mail]>>
> Cc: The IESG <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>; Qin Wu <[e-mail] <mailto:[e-mail]>>; Mahesh Jethanandani <[e-mail] <mailto:[e-mail]>>
> Subject: Re: [netconf] Roman Danyliw's Discuss on draft-ietf-netconf-trust-anchors-23: (with DISCUSS and COMMENT)
>  
> Hi Roman,
>  
> Thank you for your valuable comments.
> Please find responses below.
>  
> Kent
>  
> 
> 
> On Jan 30, 2024, at 11:47 AM, Roman Danyliw via Datatracker <[e-mail] <mailto:[e-mail]>> wrote:
>  
> 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/
> 
> 
> 
> 
> ** 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?  
>  
> Technically possible, yes.
>  
> 
> 
> What is the consequence of incorrectly binning the certificate chains?
>  
> A misconfiguration, possibly leading to trusting something in an undesirable context.
>  
> 
> 
> 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).
>  
> Each bag has a “name” and “description” fields.  From https://datatracker.ietf.org/doc/html/draft-ietf-netconf-trust-anchors-23#section-2.2.1:
>  
>     <certificate-bag>
>       <name>trusted-server-ca-certs</name>
>       <description>
>         Trust anchors (i.e. CA certs) used to authenticate server
>         certificates.  A server certificate is authenticated if its
>         end-entity certificate has a chain of trust to one of these
>         certificates.
>       </description>
>  
> So it seems very easy for clients to know a bag’s purpose without having to look at, e.g., the SAN.   
> Does this resolve your comment?
>  
> [Roman] I’m primary drilling in on the text “Each bag of certificates SHOULD be for a specific purpose”.  Since “specific purpose” has no clear, ambiguous definition, it seems like an argument could be made that almost might qualifies as a “specific purpose”.  My simple fix would be s/SHOULD/should/.


Fixed - and thank you for the the clarification!


> [snip]
>  
> ** 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?
>  
> Good point.
>  
> Hmmm, but can you clarify, is the concern limited to just the “cert-data” node (i.e., the CMS), or does it include also, e.g., the bag’s “name” and “description” nodes too?
>  
> [Roman] I’m not exactly sure how this YANG model would be used.  The cert-data node seems like it would definitely be sensitive for the reason described above.  I trust your judgement on what you anticipate the natural language descriptions might look like.  I’m not sure.

Okay, I made three changes:

1)  in the “crypto-types” draft, where the YANG groupings are defined:
	- changed "default-deny-write” to "nacm:default-deny-all”

2) also in the “crypto-types” draft, in the Security Considerations section:

	OLD:
               <t>The "cert-data" node:
                 <ul empty="true">
                   <li>The "cert-data" node, defined in both the "trust-anchor-cert-grouping"
                     and "end-entity-cert-grouping" groupings, is additionally sensitive to
                     read operations, as certificates sometimes convey personally identifying
                     information (especially end-entity certificates).  However, as it is
                     commonly understood that certificates are "public", the NACM extension
                     "nacm:default-deny-write" (not "default-deny-all") has been applied. It
                     is RECOMMENDED that implementations adjust read-access to certificates
                     to comply with local policy.</li>
                 </ul>
               </t>
 
	NEW:
               <t>The "cert-data" node:
                 <ul empty="true">
                   <li>The "cert-data" node, defined in both the "trust-anchor-cert-grouping"
                     and "end-entity-cert-grouping" groupings, is additionally sensitive to
                     read operations, as certificates may provide insight into which other
                     resources/applications/servers this particular server communicates with,
                     as well as potentially  divulge personally identifying information (e.g.,
                     end-entity certificates).  For this reason, the NACM extension 
                     "default-deny-all" has been applied.</li>
                 </ul>
               </t>


3) in *this* draft, in the Security Considerations section:

    OLD:
            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.

    NEW:
            Most of the readable data nodes defined in this YANG module 
            are not considered sensitive or vulnerable in network environments.
            However, the "cert-data" node uses the NACM "default-deny-all"
            extension, for reasons described in <xref section="3.9" target="RFCAAAA"/>.



> Roman