Re: [netconf] [Last-Call] Secdir last call review of draft-ietf-netconf-trust-anchors-13

[-last-call]

Hi Yoav,

Thank you for your review!  The takeaway for me is that some clarifications are needed, but otherwise the draft is fundamentally okay.  I will post an update, or perhaps just a GitHub commit, for your review, when I get a chance.  That said, my getting a chance will be delayed as I have a major engagement I need to focus on now.  This email is just to let you know that your review has not been forgotten.

Thanks again,
Kent

> On Sep 25, 2020, at 7:02 PM, Yoav Nir via Datatracker <noreply@ietf.org> wrote:
> 
> Reviewer: Yoav Nir
> Review result: Has Issues
> 
> I have reviewed this document as part of the security directorate's ongoing
> effort to review all IETF documents being processed by the IESG.  These
> comments were written primarily for the benefit of the security area directors.
> Document editors and WG chairs should treat these comments just like any other
> last call comments.
> 
> The document defines a YANG model for managing a trust anchor store. It allows
> two kinds of trust anchors: certificates and raw public keys. However,
> certificates are not just containers for public keys. Certificates include
> attributes about key usage, path constraints and name constraints, all of which
> constrain the ability to use the public key, and are relevant for trust
> anchors. As far as I can tell the document does not include any attributes to
> equivalently constrain the use of the raw public keys.  If the intention is
> that raw public keys will not be constrained, the document should state this
> explicitly.
> 
> Perhaps this is clear to the people who worked on the document, but it's not
> clear to me.  Are the trust anchors managed with this module supposed to be
> used to establish trust for the NETCONF or RESTCONF connections?  Section 1.1
> seems to suggest that it does, but then how is the bootstrap problem solved?
> How do we establish the NETCONF connection the first time, and if we are able
> to do that, why do we need more certificates?  If the answer is no, and the
> certificates are to be used by other protocols, then perhaps some re-wording in
> section 1.1 would help to show this. Currently, it says: "This document
> presents ... YANG modules that are part of a collection of RFCs ... define
> configuration modules for clients and servers of both the NETCONF and RESTCONF
> protocols."
> 
> The security considerations section is OK, especially sub-section 4.2.
> Sub-section 4.1 has the following:
> 
>   The YANG module defined in this document defines a mechanism called a
>   "truststore" that, by its name, suggests that it will protect its
>   contents from unauthorized modification.
> 
> Perhaps this is my different perspective, but the name doesn't lead me to
> expect that it protects its contents.  I think that the document should either
> just suggest that some mechanism to prevent unauthorized modification should be
> used, or to present such a mechanism in detail. The current text suggests is
> partially specific by mentioning digital signatures and non-volatile storage,
> but not explaining where the trust for the digital signature comes from and
> what policies govern its us:
> 
>   In order to satisfy the expectations of a "truststore", it is
>   RECOMMENDED that implementations ensure that the truststore contents
>   are signed when persisted to non-volatile memory, to prevent
>   unauthorized modifications from being made undetected.
> 
> It is too vague to be a specification, but still unnecessarily constrains the
> solution space. I think the correct thing to do is to be explicitly vague and
> to just suggest some mechanism for protecting the content.
> 
> 
> -- 
> last-call mailing list
> last-call@ietf.org
> https://www.ietf.org/mailman/listinfo/last-call