Re: [netconf] ietf crypto types - permanently hidden

Balázs Kovács <> Wed, 24 April 2019 12:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ED5B01200A1 for <>; Wed, 24 Apr 2019 05:52:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.011
X-Spam-Status: No, score=-1.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=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 JoqhVbKhQhw3 for <>; Wed, 24 Apr 2019 05:52:43 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ED5FB120086 for <>; Wed, 24 Apr 2019 05:52:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1aSDbauqddK4SrGnic0MR4teCzlptEgNnuIZC4GGOeg=; b=TWFmTyWsAF3WVJbaRC6VXcPSsM5CpbZOXCJNXVc929XJin4vX1N21Hu7SQgJ2619U7PzEHAx7RnizVFJ4vt0HYHlz7VEHfDF++PWiA5KYdlPiKV+ts7GGOulPOjBH4QoHgwoxAASt4pq+YMlQx4g7myLeCykMLceDrmT7upiscA=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.5; Wed, 24 Apr 2019 12:52:34 +0000
Received: from ([fe80::612d:6747:3f58:d6be]) by ([fe80::612d:6747:3f58:d6be%4]) with mapi id 15.20.1835.010; Wed, 24 Apr 2019 12:52:34 +0000
From: Balázs Kovács <>
To: Balázs Lengyel <>, Martin Bjorklund <>, "" <>
CC: "" <>
Thread-Topic: [netconf] ietf crypto types - permanently hidden
Thread-Index: AdTf8DCbvspujhISQkyURJOX9ReFpALufsOAAAVM5oADthG5oA==
Date: Wed, 24 Apr 2019 12:52:34 +0000
Message-ID: <>
References: <> <> <01dd01d4eb9c$b9a04160$> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: c3bfa6a6-2651-4c08-fa05-08d6c8b3b911
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:VI1PR07MB3870;
x-ms-traffictypediagnostic: VI1PR07MB3870:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <>
x-forefront-prvs: 00179089FD
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(136003)(39860400002)(366004)(396003)(189003)(199004)(13464003)(14454004)(14444005)(66574012)(966005)(7696005)(6506007)(53546011)(790700001)(68736007)(76176011)(97736004)(256004)(478600001)(33656002)(476003)(5660300002)(11346002)(446003)(2906002)(2501003)(71190400001)(71200400001)(486006)(85182001)(8676002)(81166006)(3846002)(81156014)(6116002)(8936002)(66066001)(93886005)(9326002)(86362001)(76116006)(25786009)(55016002)(66556008)(64756008)(66446008)(66946007)(66476007)(186003)(73956011)(26005)(85202003)(4326008)(6436002)(606006)(74316002)(229853002)(53936002)(316002)(102836004)(110136005)(9686003)(54896002)(6306002)(52536014)(236005)(6246003)(99286004)(7736002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB3870;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: XlT4gVOYqeTTMRX27zCjmL1ZRnbJRiL5CokrxRE6W9ZqLjuRucgjE5f5obkJ7l6/XJjRgAKp4gPRBtaUE97VGchZl2mAZapCaocYzvAKDCOSgGWGTq9rd4J0tnitqrYKYbjWyWW5nyWYd9vo9DbpKvR3llCou1yQq2mPP9k9IWpT5ioOR4Ir3URiYTXPkBuKnXeHyAIuO14d5YuCrTKPd88VPNP6PNU1Br3wRG/NqYQLTFLr1ioQpRFL1lMGc1Ls9pt/laTcgQtYWj+hRTfQWh6Vp3muAd1KIIl18gvkPgDer/aIEfOwc9PmmpzVXq/K+LILJvLcrjNfM83DVjrWWeLyAEdNUXWX0inYxI0urXE7AF1wqakHwsAPrjUzCLtAEq7f8YKoN+sV/W0C/C0lxuDeJ3Ha3zto4SQk7xabTls=
Content-Type: multipart/alternative; boundary="_000_VI1PR07MB4735949BE61335ACC8A975E7833C0VI1PR07MB4735eurp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: c3bfa6a6-2651-4c08-fa05-08d6c8b3b911
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Apr 2019 12:52:34.8057 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB3870
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: Wed, 24 Apr 2019 12:52:47 -0000


Is there a conclusion on this thread?

Alternatives I’ve seen:

  1.  ‘hidden’ actions already solve the problem.
     *   Backup of keys won’t be supported or special procedure needed.
     *   Descriptions need to be updated to generalize use case (not be restricted to TPMs).
  2.  Current actions solve the problem, but new terminology should be needed instead of ‘hidden’ and ‘permanently hidden’.
     *   Backup of keys won’t be supported or special procedure needed.
     *   Descriptions to be updated.
  3.  New actions needed that affect configuration for non-TPM use cases
     *   Backup of keys can be supported

                                                               i.      Q: how does a restore differ from normal configuration which the generate key action was supposed to circumvent to follow security best practice?

I guess the latest mails confirm 1) or 2). Would be good to know the way forward.


From: netconf <> On Behalf Of Balázs Lengyel
Sent: Friday, April 5, 2019 4:54 PM
To: Martin Bjorklund <>;
Subject: Re: [netconf] ietf crypto types - permanently hidden


While using actions to configure data nodes instead of edit-config clearly has problems, in some cases it is needed. Ericsson does use it, but we try to be VERY(!) restrictive when it is allowed. IMHO  security best practice could be one case. Also we should not pretend this is the only case where the system itself manipulates configuration:

  *   security keys
  *   HW insertion/removal (interface type)
  *   onboard automation may do it
  *   server capabilities that need additional configuration (must be in running as it is reference from other parts of the configuration)

I also hope we will arrive at a solution that works for non-NMDA systems too. AFAIK  we never stated in any RFC that NMDA is a requirement for the solution. (Except for NMDA itself :-)  )

regards Balazs
On 2019. 04. 05. 14:22, Martin Bjorklund wrote:

tom petch <><> wrote:

----- Original Message -----

From: "Martin Bjorklund" <><>

To: <><>

Cc: <><>

Sent: Thursday, April 04, 2019 6:46 PM

Juergen Schoenwaelder <><> wrote:

On Thu, Apr 04, 2019 at 04:23:23PM +0000, Kent Watsen wrote:

We have always said no, but the reasoning is unclear.  What are


specific objections and is there anyway to alleviate them?

If editing of all configuration can be done with a single edit-data

(or edit-config) operation, you simplify the world and you enable

generic implementations.

Once you build silos of data that can only be manipulated with


purpose operations, you say goodbye to the idea of generic client


And you can no longer create all required config in one transaction;

you have to split it into sending multiple special-purpose actions.

Perhaps also in a certain order, that you have to figure out somehow,

since config might have refererences to other partf of the config


You can no longer restore a backup with just a copy-config.

Which is exactly what I have seen customers - think military - do.

Security-related information - userid, passwords, second factor , ...-

MUST NOT be backed up like everything else - special procedures -

authentication, encryption -  must be used.

Agreed!  BUT, then it should not be modelled as configuration, imo.

And the current model already handles this case with "hidden" keys.


This is security - it matters.

Tom Petch

So I don't think the reasoning is unclear at all.



netconf mailing list<>


netconf mailing list<>


Balazs Lengyel                       Ericsson Hungary Ltd.

Senior Specialist

Mobile: +36-70-330-7909              email:<>