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

Sandra Murphy <> Thu, 13 August 2020 14:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7122A3A0C85; Thu, 13 Aug 2020 07:44:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZuYzQ2thihYk; Thu, 13 Aug 2020 07:44:32 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 98B083A0C84; Thu, 13 Aug 2020 07:44:31 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTP id 9EC2428B003B; Thu, 13 Aug 2020 10:44:30 -0400 (EDT)
Received: from [] (localhost.localdomain []) by (Postfix) with ESMTP id 480C61F8051; Thu, 13 Aug 2020 10:44:30 -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 <>
In-Reply-To: <>
Date: Thu, 13 Aug 2020 10:44:27 -0400
Cc: Sandra Murphy <>, Magnus Nyström <>, "" <>,,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <>
To: Kent Watsen <>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <>
Subject: Re: [secdir] (Early) Secdir review of draft-ietf-netconf-keystore
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 13 Aug 2020 14:44:35 -0000

I interpreted the “shared root key” as a key encryption key — I don’t think you eliminate any issues.

(The term is common, but I haven’t found an ietf definition to reference, so I can’t say it *is* a key encryption key.)

wrt: “one can rotate or renew the key encryption key” 

I thought the migration process might work to rotate the root key, not the “shared root key”.  So the “first server” is server Bob with root key Bob.Tues-key and “second server” is server Bob with root key Bob.Wed-key.  Do you think that works?

Magnus’ mention of “renew” brings up the topic of key lifetimes, which I realize I did not think to mention.  (Yep, out of all those words, I did not mention something I should have.)  This draft includes expiration times for the certificate, but no key lifetimes, here or in the crypto-types draft.  RFC8177 does include lifetimes for keys, for the purpose of establishing valid intervals of use and key rollover.  Was key lifetime considered?


> On Aug 10, 2020, at 9:26 PM, Kent Watsen <> wrote:
>> 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)