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

Magnus Nyström <magnusn@gmail.com> Tue, 11 August 2020 06:28 UTC

Return-Path: <magnusn@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A17A13A0CCE; Mon, 10 Aug 2020 23:28:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fmje-ZDS37QU; Mon, 10 Aug 2020 23:28:14 -0700 (PDT)
Received: from mail-oi1-x230.google.com (mail-oi1-x230.google.com [IPv6:2607:f8b0:4864:20::230]) (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 E92373A0C1C; Mon, 10 Aug 2020 23:28:13 -0700 (PDT)
Received: by mail-oi1-x230.google.com with SMTP id j7so11249325oij.9; Mon, 10 Aug 2020 23:28:13 -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 :cc; bh=lbDSMs6OaNxdGYVIjvSSuhpk6Vch2BbEUX0sY4p+fmI=; b=ls1iZHPIahK8K3GGrUsp5EUgN0MuQqdQoMKJRuy+dv97K9GS5HB3Malv2ttvnJWmH8 xl8jq+wS9YO8x05DI9kEc4MfJW67boH2fGqyHmOrqS2+YbRwr1cWImjLbOL5c7kJWpJu M4wH8aIna6E5fvARPjjgQJu7DYoc35Yf7bFsI215kA+sOG9fPgV1hUEf1sxhVrVlrdRp 4UdgKGl7FuGUR+BCg7yNo7T7gXK6BRSx/dhy6sNy0N8Rm2nfs8y1MA6dg+RCWBNSQzxU 6WHOcW3fJN0LpAALJlJ5vafKAEOecdSM8WOV3RAb3BpDbRoKXP3wiWLBEjXkEjmgnLY4 VtVg==
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:cc; bh=lbDSMs6OaNxdGYVIjvSSuhpk6Vch2BbEUX0sY4p+fmI=; b=UKUIkRFqloEvuTIoyP/dV9eP/UNmOPsLzYxEqvLvpao0oDXVYZGhodPMwZ2DwA9n/F RVJPtxmGEe0+maFyLTC6o3/qWjXBXO9Wt11uSl7nx4X2fiqgcECt2yYZxEryClVYrY4U G358FCaOuSIav/bSBV+p+sJcIKHnc76OSm1FBCH+xkGsnwyk0DgBOioZ4HNe4lwZAUFY bHTM+Lmle7CFLLBwg9Jez7PbSWaPmV0S6/W+BXAh2Qj3dHeNr5/aSp7stCMLztYv/++V 4tzeZ7RvV2F5SPGweHMFd3+KU1cPK2BOLeXHy3kxrGA69jKzzxwP7UUOx/TMJQxfyxI4 u5nA==
X-Gm-Message-State: AOAM530BinJZvBWIETzplmWiEYk27wIWxY9zhvKEfMJ8eny509SEXmnr GFgC+QTD8cNCWQiYi/gZCmABaQnUKgtGLoCA2eFTEQ==
X-Google-Smtp-Source: ABdhPJz+m8oQG4+Zk0VZSZDcHVtEOZFrOWvi7TRKo9wiAx52TFWLJ1ARC/qT+nNEbWk5Rw2liaqlBLgcXilbysYA1Ng=
X-Received: by 2002:aca:b8c4:: with SMTP id i187mr2388001oif.121.1597127293206; Mon, 10 Aug 2020 23:28:13 -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> <CADajj4Zw+Js8neUujMbekReVdMMFcz46NDwdHsMdWXob6Upc_w@mail.gmail.com> <01000173db1fc8cc-e5530e7a-c300-4f8f-8068-0fbe7fd51926-000000@email.amazonses.com>
In-Reply-To: <01000173db1fc8cc-e5530e7a-c300-4f8f-8068-0fbe7fd51926-000000@email.amazonses.com>
From: =?UTF-8?Q?Magnus_Nystr=C3=B6m?= <magnusn@gmail.com>
Date: Mon, 10 Aug 2020 23:28:00 -0700
Message-ID: <CADajj4Z+RwY48xewVnQ+Jd0CRHsr0U3G=ecgoWEAuRdwK1rm8A@mail.gmail.com>
To: Kent Watsen <kent+ietf@watsen.net>
Cc: secdir@ietf.org, draft-ietf-netconf-keystore@ietf.org, "netconf-chairs@ietf.org" <netconf-chairs@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f903e205ac942c01"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/afXMk6DdJuOFDutfmB-oUN311T4>
Subject: Re: [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: Tue, 11 Aug 2020 06:28:16 -0000

Hi Kent,
On the metadata, yes, I did catch that the actual values are protected. My
suggestion (it is entirely up to the group of course) was just to consider
if any of the data that will be readable may warrant a similar restriction
as you have for the actual key values.

On the root key etc., - OK, I understand now. I am also good with your
other updates.

Thanks!
/M


On Mon, Aug 10, 2020 at 6:26 PM Kent Watsen <kent+ietf@watsen.net> wrote:

> [CC-ing netconf-chairs]
>
>
> Hi Magnus,
>
> Thank you for the review.  Below are some comments, as well as a link to
> the GitHub commit, and an updated plain-text version of the draft.
>
> Thanks,
> Kent
>
>
> On Aug 10, 2020, at 1:29 AM, Magnus Nyström <magnusn@gmail.com> wrote:
>
> 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."
>
>
> Good catch.  r/all the private keys/both the symmetric and asymmetric 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.
>
>
> What you say is the intention, but the terminology used seems to be off.
> The alignment needed is:
>
>   Root key —> Master Encryption Key (MEK)
>   Shared root key —> Key Encryption Key (KEK)
>
>
>
> 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.
>
>
> I think there is a subtly you may be missing.  The keystore module uses
> the key definitions defined in the crypt-types draft.  In that draft, the
> key data *is* flagged with the “nacm:default-deny-all” extension.  So the
> key data itself (e.g., an ECPrivateKey or AESKey, in OpenSSL parlance) is
> protected.  Is that sufficient to protect the key metadata mentioned...or
> are you concerned about the “key-format” and/or “public-key” nodes being
> readable?
>
>
>
> *Editorial:*
>
> ( A few nits that I found )
>
> Section 1:
>
>    - Substitute "Trusted Protection Module" with "Trusted Platform Module"
>    - The term "HSM" is used without explanation
>
> Both fixed in my local copy - thanks!
>
>
>    - Last sentence (starting: "It is also possible...") is garbled
>
>
> Now reads:
>
>           "It is also possible that a
>           system implementing this module possesses a multiplicity of
>           operating system level keystore utilities and/or HSMs."
>
> Better?
>
>
>
> Section 1.1:
>
>    - Sentence starting "Links the each" is garbled
>
> Section 3:
>
>    - Second sentence starts "Built-in built-in keys..."
>
>
> Both fixed in my local copy - thanks!
>
>
>
>
>
> The GitHub commit enacting the updates is here:
> https://github.com/netconf-wg/keystore/commit/5b3b9f3db0d6b7027ddf5f0e983ab958e8802251
>
> The plain-text version of the updated draft is attached.
>
> Thanks again!
> Kent
>
>
> /M
>
>
>
>
>
>

-- 
-- Magnus