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

Kent Watsen <> Fri, 02 October 2020 11:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E2FFA3A15C3; Fri, 2 Oct 2020 04:20:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MXZxjh-F5QE4; Fri, 2 Oct 2020 04:20:22 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 82DD23A15C1; Fri, 2 Oct 2020 04:20:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono;; t=1601637618; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=112F6c+AZZkoAf53im10KaL8T+6upaTyW03lQVNDbbc=; b=ivStbwmgNGzf5ac4tYmm1PJa9a9HgKGc1/JAmyCncLhRHqmzrr67cIIUCyy9Q4bc 7iqk0luNra/Mm5CzjYJdyamHh1DJFOG7599nKggfUk69TKl4PoV7GSfHVuUESUfpZ3C SGgpBpbQk8P4ahsDkyPd5mxJCIdPifpp8qzaaf/Y=
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Kent Watsen <>
In-Reply-To: <>
Date: Fri, 02 Oct 2020 11:20:18 +0000
Cc:, "" <>,
Content-Transfer-Encoding: quoted-printable
Message-ID: <>
References: <>
To: Yoav Nir <>
X-Mailer: Apple Mail (2.3608.
X-SES-Outgoing: 2020.10.02-
Archived-At: <>
Subject: Re: [netconf] [Last-Call] Secdir last call review of draft-ietf-netconf-trust-anchors-13
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 02 Oct 2020 11:20:24 -0000


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,

> On Sep 25, 2020, at 7:02 PM, Yoav Nir via Datatracker <> 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