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

Kent Watsen <kent+ietf@watsen.net> Wed, 12 August 2020 14:35 UTC

Return-Path: <01000173e318a0ab-ab85dee0-63dd-4477-9f3b-006c6ffbfcf1-000000@amazonses.watsen.net>
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 B6CA13A12E7; Wed, 12 Aug 2020 07:35:11 -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 a_bFzdPqrHef; Wed, 12 Aug 2020 07:35:10 -0700 (PDT)
Received: from a48-93.smtp-out.amazonses.com (a48-93.smtp-out.amazonses.com [54.240.48.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DDCE3A12D3; Wed, 12 Aug 2020 07:35:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1597242909; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=BWQbyl58R5c+mMQU3ANsUUIXKBp1mKzfM9dP689Q74E=; b=AjLrpLAKNXE6B4WF1k3piKvl2X4oU6945wthIkDvuCekbPRCm5/54Ky4RxeV1VbP sxPLKFKzJCCJqzNl4BuOj4T0o2V3gaVC8HGoBWt2XcyqNSywO7MtodBXB1PXDtAOVxF fkTFQ8z4haTX/blWOri2bs51WOjUN3aKT+I6LVrA=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Kent Watsen <kent+ietf@watsen.net>
In-Reply-To: <CADajj4Z+RwY48xewVnQ+Jd0CRHsr0U3G=ecgoWEAuRdwK1rm8A@mail.gmail.com>
Date: Wed, 12 Aug 2020 14:35:09 +0000
Cc: secdir@ietf.org, draft-ietf-netconf-keystore@ietf.org, "netconf-chairs@ietf.org" <netconf-chairs@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-ID: <01000173e318a0ab-ab85dee0-63dd-4477-9f3b-006c6ffbfcf1-000000@email.amazonses.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>
To: =?utf-8?Q?Magnus_Nystr=C3=B6m?= <magnusn@gmail.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-SES-Outgoing: 2020.08.12-54.240.48.93
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/weBQ1yPYhnlgr3f_QGmn_DlurLg>
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: Wed, 12 Aug 2020 14:35:12 -0000

Hi Magnus,

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?  - it was effectively completely rewritten to align with the Key Encryption Key and Master Key terminology...

PS: Sandy’s response is massive, but it refers to the old Section 4 text so, before digging into it, I want to ensure that you’re happy with the new text.

Kent



> On Aug 11, 2020, at 2:28 AM, Magnus Nyström <magnusn@gmail.com> wrote:
> 
> 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