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

Kent Watsen <kent@watsen.net> Fri, 02 October 2020 11:20 UTC

Return-Path: <01000174e90a9186-0a4edb66-4120-44b7-a79f-7b9935f6d48f-000000@amazonses.watsen.net>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2FFA3A15C3; Fri, 2 Oct 2020 04:20:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXZxjh-F5QE4; Fri, 2 Oct 2020 04:20:22 -0700 (PDT)
Received: from a48-94.smtp-out.amazonses.com (a48-94.smtp-out.amazonses.com [54.240.48.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (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; d=amazonses.com; 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.80.23.2.2\))
From: Kent Watsen <kent@watsen.net>
In-Reply-To: <160107496501.14047.597283542214697710@ietfa.amsl.com>
Date: Fri, 2 Oct 2020 11:20:18 +0000
Cc: secdir@ietf.org, "netconf@ietf.org" <netconf@ietf.org>, draft-ietf-netconf-trust-anchors.all@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-ID: <01000174e90a9186-0a4edb66-4120-44b7-a79f-7b9935f6d48f-000000@email.amazonses.com>
References: <160107496501.14047.597283542214697710@ietfa.amsl.com>
To: Yoav Nir <ynir.ietf@gmail.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-SES-Outgoing: 2020.10.02-54.240.48.94
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/L305enMYA8pIXnpH0J7wmQTv9YI>
Subject: Re: [netconf] [Last-Call] Secdir last call review of draft-ietf-netconf-trust-anchors-13
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Oct 2020 11:20:24 -0000

[-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