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

Benjamin Kaduk <> Wed, 30 December 2020 01:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 035E13A0D85; Tue, 29 Dec 2020 17:17:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vmwkwdUEKo8i; Tue, 29 Dec 2020 17:17:11 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5164A3A0D82; Tue, 29 Dec 2020 17:17:09 -0800 (PST)
Received: from ([]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.14.7/8.12.4) with ESMTP id 0BU1H2Le015105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 29 Dec 2020 20:17:06 -0500
Date: Tue, 29 Dec 2020 17:17:01 -0800
From: Benjamin Kaduk <>
To: Kent Watsen <>
Cc: Yoav Nir <>, "" <>,,
Message-ID: <>
References: <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
Archived-At: <>
Subject: Re: [netconf] [secdir] [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: Wed, 30 Dec 2020 01:17:13 -0000

Hi Kent,

I'm not Yoav, but...

On Wed, Dec 23, 2020 at 12:35:32AM +0000, Kent Watsen wrote:
> Hi Yoav,
> I finally found some time  :sigh:   ;)
> Please see below for responses to your comments.
> Kent
> > On Oct 2, 2020, at 7:20 AM, Kent Watsen <> wrote:
> > 
> > [-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 <> 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.
> Good catch.  You’re right that this document is not constraining the raw keys in the truststore.  Looking deeper, I see that the keys are unconstrained in both the “keystore” draft and the common “crypto-types” draft.  It seems like the right thing to do is to put a Security Consideration note into each draft.  Something like this?
>    4.2.  Unconstrained Public Key Usage
>       This module enables the configuration of public keys without
>       constraints on their usage, e.g., what operations the key is allowed
>       to be used for (encryption, verification, both).
>       This module also enables the configuration of certificates, where
>       each certificate may constrain the usage of the public key according
>       to local policy.
> Thoughts?

This doesn't really fill me with joy.  In short, constraints are going to
have to be applied at *some* level, even if it's not this one, or the
system as a whole is likely to have some very surprising security
properties.  I recognize that coming up with a new language to describe
this sort of constraints is neither fun nor easy (and trying to repurpose
an existing language, such as that used by X.509, is not without issues
either), but I'd hope we could come up with something to say about how to
effectively use constraints on raw public keys.