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

Magnus Nyström <magnusn@gmail.com> Thu, 13 August 2020 06:26 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 62A753A05DE; Wed, 12 Aug 2020 23:26:27 -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 261bgeYEL4Ng; Wed, 12 Aug 2020 23:26:25 -0700 (PDT)
Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) (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 0353C3A0645; Wed, 12 Aug 2020 23:26:24 -0700 (PDT)
Received: by mail-oi1-x235.google.com with SMTP id e6so4127784oii.4; Wed, 12 Aug 2020 23:26:24 -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=GmtDckQoxfWeCWqCT5tXDTxLO5OuJG9i/YQ9uoyRGQ4=; b=XaDjJ2B0UZi/H/HEzuanCfL0AyYgkCV3ONnsAGBsEBpsLL/c66AyBidWm2/L0QYZwV 5NJxfU912sxsQx9V51CZB+1hCZZsD+fBFZ45U1xoUMosrYonuQBar553YnIPoJuDXo/B 8LtI6o8U4taf4SQMaVCAibRlkUb6ziC+Xu2mt2xY7X8JwyMM+LJEL887p2PpsC7afIH3 sARvB7TF2WDpdMNXw3PCaYv3ku3B8bHCixq7oNNNYsL/sIKdcGK3i6zlyFrlMQFlMCdO PpVlgzjUwiDmuyw0zA3U+gkHU+/qWQz7sTmgtdJ77ZrTP1UmBE4OnqBUoty6c4PG3E+s kTXA==
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=GmtDckQoxfWeCWqCT5tXDTxLO5OuJG9i/YQ9uoyRGQ4=; b=L/ZwQM9GaTkVL0fhTtDYpv+9Igw2QMA3EZTNAHc5opX8bLqOduiUFqBwNASZUkwTHK B8fekWPF9CFjmgtr5M7sGhNQXMPPFxi4Hv5EQXYaGyZOfOjCByhSzfVl3wLV5YOY6g6x pTHvPe641xCEx228Wh5L7AMcFKpLP2CBSFCOjEE9TOqkMIn78O9/wreQWC2Iy9hjPHpe F5umeZuhQmnQJ1gmQ8Hxw+hw218IiR8V5gY7hcnh5gOQzFdMGyejAOCLanqk3Zg5Qjbw GFKpepYU6R15IXJ9urSLHveJhN1SQdIalQDUVeqI1H/DIvzlSm6almQgBpWyWkO7M4uo Mnbw==
X-Gm-Message-State: AOAM532ezMKa23BumErs3kqsHV3jNhnkotr40pG2RcRExeQP6kFtq0fl iO0KWMriaB0M90SO7K3U+83PCDmK7BFb9fbBslI=
X-Google-Smtp-Source: ABdhPJzd3gKBQyXjeqsEjmcWqekiLqxFVfGHOlGgiptzPfBGwdE9F6doUCo3IjWuqob0ZhAJ+AYsN2v20VIVupwYoIo=
X-Received: by 2002:aca:eb84:: with SMTP id j126mr2246371oih.30.1597299984100; Wed, 12 Aug 2020 23:26:24 -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> <CADajj4Z+RwY48xewVnQ+Jd0CRHsr0U3G=ecgoWEAuRdwK1rm8A@mail.gmail.com> <01000173e318a0ab-ab85dee0-63dd-4477-9f3b-006c6ffbfcf1-000000@email.amazonses.com>
In-Reply-To: <01000173e318a0ab-ab85dee0-63dd-4477-9f3b-006c6ffbfcf1-000000@email.amazonses.com>
From: =?UTF-8?Q?Magnus_Nystr=C3=B6m?= <magnusn@gmail.com>
Date: Wed, 12 Aug 2020 23:26:12 -0700
Message-ID: <CADajj4Yftrh6WLqCEay7m5=2i5GSp35KJ-effscyp+SpcdVAqQ@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="00000000000026f1c805acbc62b4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/C_zlVeL5Hzh76TMnlamxXvsOEno>
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 06:26:28 -0000

Hi Kent,
I did review the updated Section 4 and I think it looks good. A couple of
minor suggestions:

   - You could replace "Master Encryption Key (MEK)" with just "Master Key
   (MK)," it is a more common term I think.
   - In addition, I would suggest replacing 'In order to decouple the
   crypto officers from the regular administrators, a second KEK, called the
   "master encryption key" (MEK), is used." with "In order to decouple the
   crypto officers from the regular administrators, a second KEK, called the
   "master encryption key" (MEK), MAY be used."
   (The "MAY" shows there are more options)

Thanks,
/M

On Wed, Aug 12, 2020 at 7:35 AM Kent Watsen <kent+ietf@watsen.net> wrote:

> 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
>
>

-- 
-- Magnus