Re: [netconf] ietf crypto types - permanently hidden

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Thu, 30 May 2019 14:47 UTC

Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 266EF12004E for <netconf@ietfa.amsl.com>; Thu, 30 May 2019 07:47:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 h6qnTJr6MDBQ for <netconf@ietfa.amsl.com>; Thu, 30 May 2019 07:47:19 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 052C8120046 for <netconf@ietf.org>; Thu, 30 May 2019 07:47:19 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id CEF5B81A; Thu, 30 May 2019 16:47:16 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.198]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id M6dG2HZoq2J7; Thu, 30 May 2019 16:47:16 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu, 30 May 2019 16:47:16 +0200 (CEST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id B6B6D20128; Thu, 30 May 2019 16:47:16 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id 9RDJgy00h3Tl; Thu, 30 May 2019 16:47:16 +0200 (CEST)
Received: from exchange.jacobs-university.de (sxchmb04.jacobs.jacobs-university.de [10.70.0.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 62A6B20126; Thu, 30 May 2019 16:47:16 +0200 (CEST)
Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1713.5; Thu, 30 May 2019 16:47:15 +0200
Received: by anna.localdomain (Postfix, from userid 501) id 85F25300990D77; Thu, 30 May 2019 16:47:15 +0200 (CEST)
Date: Thu, 30 May 2019 16:47:15 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Kent Watsen <kent@watsen.net>
CC: =?utf-8?B?QmFsw6F6cyBLb3bDoWNz?= <balazs.kovacs@ericsson.com>, "netconf@ietf.org" <netconf@ietf.org>
Message-ID: <20190530144715.ypon36hh62mhbk3f@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Mail-Followup-To: Kent Watsen <kent@watsen.net>, =?utf-8?B?QmFsw6F6cyBLb3bDoWNz?= <balazs.kovacs@ericsson.com>, "netconf@ietf.org" <netconf@ietf.org>
References: <0100016a7e7a9e54-d4987061-96d8-49f3-a2bf-36b98851b3a3-000000@email.amazonses.com> <0100016a7e822689-e6fdbdbe-ba84-43e1-aefe-47196fe692e3-000000@email.amazonses.com> <e6930b6e52a642bda9f1bd76731ce9c3@XCH-RCD-007.cisco.com> <20190507.141926.1879619200930898148.mbj@tail-f.com> <0100016a942528d9-f65afd2a-2cc7-451d-93d8-788495f6a13a-000000@email.amazonses.com> <20190508054622.rz64qmxdhbx53x4g@anna.jacobs.jacobs-university.de> <0100016aa7b06b97-15f7703f-58b7-40a9-8afe-a54dd2b809e2-000000@email.amazonses.com> <0100016aeb7ee1aa-93dbb2f2-f4ff-432f-9a26-a10abb96b03b-000000@email.amazonses.com> <VI1PR07MB4735A8741475AB48FC53FACD83180@VI1PR07MB4735.eurprd07.prod.outlook.com> <0100016b09177be4-ad12ed9f-ddc5-4c13-9470-39b2768513cb-000000@email.amazonses.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <0100016b09177be4-ad12ed9f-ddc5-4c13-9470-39b2768513cb-000000@email.amazonses.com>
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB01.jacobs.jacobs-university.de (10.70.0.120) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/ksxlaFZrr8Isj72fBM9z-go84PI>
Subject: Re: [netconf] ietf crypto types - permanently hidden
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 May 2019 14:47:22 -0000

On Thu, May 30, 2019 at 02:14:22PM +0000, Kent Watsen wrote:
 
> I'm growing weary of this discussion.  Perhaps we should do even less for the first release of the crypto-types module.  That is, instead of:
> 
>    leaf private-key {
>      nacm:default-deny-all;
>      type union {
>        type binary;
>        type string {
>          pattern
>            '<permanently-hidden>'
>          + '|<encrypted by="*">[A-Za-z0-9+/]+[=]{1,3}'
>          + '|<value-to-be-generated(-and-hidden)?>'
>          + '|<value-to-be-hidden>[A-Za-z0-9+/]+[=]{1,3}';
>        }
> 
> we have:
> 
>    leaf private-key {
>      nacm:default-deny-all;
>      type union {
>        type binary;
>        type string {
>          pattern
>            '<permanently-hidden>'
>          + '|<encrypted by="*">[A-Za-z0-9+/]+[=]{1,3}'
>        }
> 
> 
> This removes the "verbs" (as you call them) and thus leaves open possibility for either "verbs" or action statements to be added in some future revision.   This subset still supports the critical use-case of a manufacturer-generated private key for a secure device identifier (i.e., IDevID).    Unfortunately, it does not support the security best practice use-case of having the device generate the private key.  The IESG (Security Directorate) may or may not be okay with this (obviously the shepherd would have to bring it to their attention), but perhaps it's worth testing their resolve and see what happens?
>

Some comments:

- Not sure what security best practice is and where it is defined.
  Creating the key on the device has the benefit that the key may
  never have to leave the device but it also requires that I can trust
  the device to create good keys. (People recall the glitch that led
  to weak openssh keys on many Linux systems? And given todays world,
  which devices should I trust to generate strong keys?) I might
  decide that creating keys with known software I am willing to trust
  is far better than trusting a key generator shipped by a random
  device manufacturer.

- Side effects are bad and should be avoided. If something requires an
  rpc/action, make it an rpc/action.

- If you create something, give it a name; once things are named (or
  have other unique properties), config can then refer to these named
  objects. A create key operation might simply return a fingerprint
  for the key as the key's name.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>