Re: [netconf] ietf crypto types - permanently hidden

Kent Watsen <> Thu, 02 May 2019 00:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 468F8120089 for <>; Wed, 1 May 2019 17:34:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id b5vMsQ0N17cf for <>; Wed, 1 May 2019 17:34:21 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8263812006B for <>; Wed, 1 May 2019 17:34:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw;; t=1556757260; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=EU21l/2xKfQtRzRY4FHOfzTVI5WALk2pjwVnwEbX2GI=; b=YN0Qf3d1G1KGz6Rz2OdZuQiqvXGSbcZFpB2cB++EfdXYOd5J4Rbgv91Lj8s2DJKN +//3FXb5pRvnt9bMJWXFc4gjyg5+qPhC7EZWY9Gco++ss4898iBr5wDRa36qaU9Od9A WbvJPzaw33DbCh4Kfqic2pOM0COU3CSg7unIkS8I=
From: Kent Watsen <>
Message-ID: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_039D6799-5356-4AAA-A7F0-FD82F2A2D78F"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Thu, 02 May 2019 00:34:20 +0000
In-Reply-To: <>
Cc: "Rob Wilton (rwilton)" <>, "" <>
To: Andy Bierman <>
References: <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3445.102.3)
X-SES-Outgoing: 2019.05.02-
Archived-At: <>
Subject: Re: [netconf] ietf crypto types - permanently hidden
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 02 May 2019 00:34:23 -0000

> The document-oriented configuration came from a requirement identified
> at the IAB Network Management Workshop (way back when).
> It is critical for rebooting, swapping out a defective device, etc.

Regarding the document-model concern, here is a line of thinking that may help this discussion:

We recently removed the "cannot be backed-up language" because there may be a way for a device to backup a permanently hidden key, even when protected by a TPM.

Specifically, a TPM (I don't know about other crypto processors) is able to encrypt TPM-protected keys (using yet another TPM-protected key called the storage root key, SRK), thus the key (albeit encrypted) CAN be backed up, but it CAN ONLY be restored on the device having the originating TPM.

Thus, instead of using the enum "permanently-hidden", the value of the *encrypted* key could be safely provided.

Perhaps we could model the 'private-key' value after iana-crypt-hash and prefix the base64-encoded binary private key value with some special (not legal base64) value indicating that the key is 1) encrypted and 2) can only be restored on the originating device.  Ideally, the prefix identifies the device (or, better, the crypto processor), lest there is any confusion.

As for "swapping out a defective device", the above idea doesn't support that workflow, but I think that the inability to do a full RMA is given with the meaning of a "permanently-hiddden" key already and, anyone that creates such a key does so with that understanding.   What it does support, though, is the full restoration of the device after a hard-drive replacement (or reformat) using a standard "configuration" document, which seems better than what we have now with the "permanently-hidden" enum.

> The "server created config" problem could be viewed as an access control problem.
> There are proprietary YANG extensions that implement this approach.

I don't understand, can you provide examples?

Kent // contributor