IETF Logo Mail Archive

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

Sandra Murphy <sandy@tislabs.com> Thu, 13 August 2020 15:16 UTC

Return-Path: <sandy@tislabs.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 1C3EF3A0D17; Thu, 13 Aug 2020 08:16:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 zrBmuYSf9_Sr; Thu, 13 Aug 2020 08:16:22 -0700 (PDT)
Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E82A3A0D0D; Thu, 13 Aug 2020 08:16:21 -0700 (PDT)
Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 7F84B28B003B; Thu, 13 Aug 2020 11:16:20 -0400 (EDT)
Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 0DBE21F8051; Thu, 13 Aug 2020 11:16:20 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Sandra Murphy <sandy@tislabs.com>
In-Reply-To: <01000173e318a0ab-ab85dee0-63dd-4477-9f3b-006c6ffbfcf1-000000@email.amazonses.com>
Date: Thu, 13 Aug 2020 11:16:17 -0400
Cc: Sandra Murphy <sandy@tislabs.com>, Magnus Nyström <magnusn@gmail.com>, "netconf-chairs@ietf.org" <netconf-chairs@ietf.org>, draft-ietf-netconf-keystore@ietf.org, secdir@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <4259FA7C-8A2F-4F3E-B998-CD870EE9E3C0@tislabs.com>
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> <CADajj4Z+RwY48xewVnQ+Jd0CRHsr0U3G=ecgoWEAuRdwK1rm8A@mail.gmail.com> <01000173e318a0ab-ab85dee0-63dd-4477-9f3b-006c6ffbfcf1-000000@email.amazonses.com>
To: Kent Watsen <kent+ietf@watsen.net>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/RafwyYbQmsiGYxXT-riET6sYUrc>
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: Thu, 13 Aug 2020 15:16:23 -0000


> On Aug 12, 2020, at 10:35 AM, Kent Watsen <kent+ietf@watsen.net> wrote:
> 
> I just want to confirm, did you read the new Section 4 (Encrypting Keys in Configuration) in the plain-text draft I attached in my previous response? 

Taking a look at -20, it looks like Section 4 is the only change (of substance).

I see that you removed the early paragraph that says the root key should be hidden but might be unhidden with careful access control.  Have you abandoned the idea of an unhidden root key (aka MEK)?

The revisions have eliminated the "Given the long lifetime of built-in keys (see Section 3), built-in keys MUST be hidden.”  Did you intend to eliminate that?

Are MEK and KEK the only keys that can be used to encrypt other keys?  I thought the YANG model permitted using a reference to any keystore key in the encrypted-by field.

—Sandy

v2.23.0 | Report a Bug | By Email