[secdir] (Early) Secdir review of draft-ietf-netconf-keystore

Magnus Nyström <magnusn@gmail.com> Mon, 10 August 2020 05:29 UTC

Return-Path: <magnusn@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 9A6563A08EB; Sun, 9 Aug 2020 22:29:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id seC9NNj9d-MK; Sun, 9 Aug 2020 22:29:45 -0700 (PDT)
Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E83C3A08A2; Sun, 9 Aug 2020 22:29:42 -0700 (PDT)
Received: by mail-ot1-x330.google.com with SMTP id 93so6399091otx.2; Sun, 09 Aug 2020 22:29:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=dq91Agw6cvbDrJOQhUAvccQn7gL8Zwpg4Vp3uTT8+1U=; b=fT7sb//PNmdnkTVYL1ohrH2Fp6lmqdSeBAK8Wp1kEM0njVoueUKzBOL6QgR+GCE/8c bCEMdielLQccz9SREu2hhRLBh7DLlPUqg0xlXpVc3KhwY/vx5v8Z4YcaLAG6ShVt2iAZ haq2RfRFbw/G9UrSvYysB9AHAc5r+RI8WNzM9fAO6KKjqLiWam1lP/gV7XOIbIDgKQQv CzRe4Wa5FVz8X5ZyFnxqhodDojXH00qcFYdaswEwhD5qF3pE3kcSVfHcqy///GhFyDaP Nv1J8RKIAw/PaymtomVMZUfZ141dt7N7w835IiWyx+8ez2RkQiPfXA8GFkv95YP5FCYR hdxg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=dq91Agw6cvbDrJOQhUAvccQn7gL8Zwpg4Vp3uTT8+1U=; b=GNYEXpy5IXmUSNAPKbMi3cVqnztqQJCLQVJmkxFI1Cw6iXa92L75Sh8+j82yqvetyA Ur274mu7cgXIGHi2IrSQtkjWgFzlqoYGAwgOxc9dEWRnfbbYp2hvBWqLrr7sUu+D3AEm nwNMXrFKuypM7Xxjc9lUn2O4ygzdMA+H16J1kXnARMUrfztXYNq0gnv7LW3Y6qj5F2/9 +Uy1I96lKVeQnoRdiGQ89tNEEC6T/GysntX0vQF12OuttXJLeLHU/4/roBxOyrOr2S6w 2FzrdRToVNyldDNFOmwszChHYlUHFXDGdFEjG29wzVYFs4S+SFQ9U23Y4Xg1B7cDr19n d8Zw==
X-Gm-Message-State: AOAM532e+nwUDcbVCom0H+gzKGTGsygWyp2Hq+42fqZnAcPuXy0NT1yf IzKWLj2tHiGkAUsZ1jU+3PMdU7PTxQBNH/CzTKpt8bCl
X-Google-Smtp-Source: ABdhPJytCssruFZmREgbQ3f0L7OQr859PcwhNW6Q3DlGLzVbPjnrCpq6k8GEbqOFOBvOlnX8SVyOFBxyFpleoUGbrUM=
X-Received: by 2002:a9d:2203:: with SMTP id o3mr20639489ota.149.1597037381358; Sun, 09 Aug 2020 22:29:41 -0700 (PDT)
MIME-Version: 1.0
References: <CADajj4ZQnWkjKdWpBgsB0oyX8_Kzj6HOL-Vkm=TrByBQMEJfPw@mail.gmail.com> <CADajj4bCTF5EeF6DZkCHpP0_GTnUYQtqa0OE3qf3Z5_AmKWfyA@mail.gmail.com> <CADajj4YxgdNXkWX7dLP0nBDWXLSKFa8M_KWWCPCgfCibYtWkAw@mail.gmail.com> <CADajj4Yw13QWbSqF_hd+P_fcNA4_YvdwqF=OgJ4pdS_1vrWphA@mail.gmail.com>
In-Reply-To: <CADajj4Yw13QWbSqF_hd+P_fcNA4_YvdwqF=OgJ4pdS_1vrWphA@mail.gmail.com>
From: Magnus Nyström <magnusn@gmail.com>
Date: Sun, 09 Aug 2020 22:29:32 -0700
Message-ID: <CADajj4Zw+Js8neUujMbekReVdMMFcz46NDwdHsMdWXob6Upc_w@mail.gmail.com>
To: secdir@ietf.org, draft-ietf-netconf-keystore@ietf.org
Content-Type: multipart/alternative; boundary="000000000000cf17ef05ac7f3d1b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/yls-6-5TvBExT9AjWLfzEyl5Ua4>
Subject: [secdir] (Early) Secdir review of draft-ietf-netconf-keystore
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Aug 2020 05:29:47 -0000

 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.

This document describes a new YANG model for centralized configuration of
cryptographic keys in the context of NETCONF and RESTCONF.

Section 4 describes a process to encrypt all "private" keys in a
configuration. It is unclear if this refers only to the asymmetric keys in
the configuration (as "private keys" normally refer to asymmetric keys) or
also symmetric keys. It appears to apply to all cryptographic keys, and it
therefore seems better to replace this usage of "private" with "symmetric
and asymmetric private keys."

Likewise, the use of the term "root key" is a bit unclear. A "root key"
normally refers to an asymmetric key, but in this text it could be either.

More broadly, it may be advantageous to consider a hierarchy, where a key
encryption key is used to encrypt all keys in a configuration and this key
encryption key in turn is protected by a root (or master) key. This way,
two instances only need to share the key encryption key and there's no need
for shared root keys (which may present an issue). Likewise, one can rotate
or renew the key encryption key if desired, whereas this usually is harder
for root keys.

Section 5.2 first states: "The NACM "default-deny-all" extension has not
been set for any data nodes defined in this module," ostensibly because
"none of the readable data notes ... are considered sensitive." I note here
that meta-data about keys oftentimes can provide valuable information about
those keys and suggest considering if the default-deny-all extension should
be set by default after all.


( A few nits that I found )

Section 1:

   - Substitute "Trusted Protection Module" with "Trusted Platform Module"
   - The term "HSM" is used without explanation
   - Last sentence (starting: "It is also possible...") is garbled

Section 1.1:

   - Sentence starting "Links the each" is garbled

Section 3:

   - Second sentence starts "Built-in built-in keys..."