Skip to main content

Last Call Review of draft-ietf-netconf-trust-anchors-13
review-ietf-netconf-trust-anchors-13-secdir-lc-nir-2020-09-25-00

Request Review of draft-ietf-netconf-trust-anchors
Requested revision No specific revision (document currently at 28)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2020-08-06
Requested 2020-07-09
Requested by Mahesh Jethanandani
Authors Kent Watsen
I-D last updated 2020-09-25
Completed reviews Genart Last Call review of -22 by Paul Kyzivat (diff)
Secdir Last Call review of -24 by Yoav Nir (diff)
Secdir Last Call review of -13 by Yoav Nir (diff)
Yangdoctors Last Call review of -13 by Jürgen Schönwälder (diff)
Assignment Reviewer Yoav Nir
State Completed
Request Last Call review on draft-ietf-netconf-trust-anchors by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/ILutx6V1_fSZ4GLfe75FrPImVp8
Reviewed revision 13 (document currently at 28)
Result Has issues
Completed 2020-09-25
review-ietf-netconf-trust-anchors-13-secdir-lc-nir-2020-09-25-00
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.