[secdir] Secdir last call review of draft-ietf-netconf-trust-anchors-13

[Yoav Nir via Datatracker <[e-mail]>]

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.