Re: [netconf] ietf crypto types - permanently hidden

Balázs Lengyel <> Fri, 05 April 2019 14:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D9C43120482 for <>; Fri, 5 Apr 2019 07:53:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.298
X-Spam-Status: No, score=-0.298 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, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ikl6HYOOAe4H for <>; Fri, 5 Apr 2019 07:53:57 -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 3F4DE12046B for <>; Fri, 5 Apr 2019 07:53:51 -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=poxMd+DKzEfZx0cPP2u+Cvfp4FksJLKsAhhM33gChH8=; b=P8WeQBYq6AvzfAPX4Fzhbbu04Xs013BLVgPgHNBFSQkW1n0etAIWzf32qREm0gIzt3LldymyiueRpNFHDc1Rf8JCzyssz3Q25ZICCbnGDokzC8Fg9hT1k7Nxbt6+pgTeLF7cnDQzXaZpUXsNL9gOczJpA6mpYnlwZGd9DGtdZt8=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.8; Fri, 5 Apr 2019 14:53:48 +0000
Received: from ([fe80::20ca:9699:6d54:1543]) by ([fe80::20ca:9699:6d54:1543%7]) with mapi id 15.20.1771.006; Fri, 5 Apr 2019 14:53:48 +0000
From: Balázs Lengyel <>
To: Martin Bjorklund <>, "" <>
CC: "" <>
Thread-Topic: [netconf] ietf crypto types - permanently hidden
Thread-Index: AQHU679f1WNMIVsqeEG2PDBEdPRHrw==
Date: Fri, 05 Apr 2019 14:53:47 +0000
Message-ID: <>
References: <> <> <01dd01d4eb9c$b9a04160$> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-originating-ip: []
user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
x-clientproxiedby: AM6P194CA0053.EURP194.PROD.OUTLOOK.COM (2603:10a6:209:84::30) To (2603:10a6:3:72::10)
authentication-results: spf=none (sender IP is );
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 600836b4-4a2e-4a3a-8dd0-08d6b9d68219
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(49563074)(7193020); SRVR:HE1PR0701MB2092;
x-ms-traffictypediagnostic: HE1PR0701MB2092:
x-microsoft-antispam-prvs: <>
x-forefront-prvs: 0998671D02
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(366004)(396003)(39860400002)(376002)(346002)(13464003)(189003)(199004)(386003)(6506007)(26005)(478600001)(71200400001)(71190400001)(5660300002)(229853002)(256004)(93886005)(14444005)(52116002)(6306002)(2501003)(53936002)(54896002)(966005)(8936002)(4326008)(36756003)(68736007)(64126003)(81166006)(486006)(31696002)(86362001)(106356001)(8676002)(102836004)(85202003)(105586002)(81156014)(476003)(6486002)(25786009)(606006)(2616005)(6246003)(99286004)(97736004)(11346002)(2906002)(76176011)(7736002)(31686004)(446003)(6436002)(65806001)(65956001)(66066001)(186003)(65826007)(85182001)(3846002)(6116002)(99936001)(6512007)(110136005)(14454004)(236005)(316002)(58126008); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2092;; 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: 4Subje+lgNNuRSnU3U6PkVk1GJA/lQZEHyhkgJ2wm0Xvgq44Vl0KcWf4zTblXu1zUTFQWrDbDuy+8Xw5ryK5qr3XmMYt0J8bqZX6AX/TQgSELgdpFAPY8YCWdGkzBtcP+QJzAUNifILh7PEbNIeRFtB7DVFpogzOzGZq+Sc0udjwxuZ976YVEq2bfGJUk6/BauK8KTfIwVej3OMVJfmdjo+rO9O+BJ8WaBh0ncl8X1TT3FJLAbxriJk2xSe/ru9vvUrvXgiAJBdherxX2tiZf8zVIa4zT0dOQHwlNaOLL3WOMHc5gKH9TGO0gTsf89aZAE5q0CJDo7qgufTjlZNeY36H+35WyN7MJMd7Wynw8dGYO2c6gO6DBOTTiwz6rYinJso5isUkdSVOO3J7otSk61lk9LNYBeCwtJw00UXmBEs=
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms030100080606040406020605"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 600836b4-4a2e-4a3a-8dd0-08d6b9d68219
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Apr 2019 14:53:48.0179 (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: HE1PR0701MB2092
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: Fri, 05 Apr 2019 14:54:00 -0000


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" rel="nofollow">

netconf mailing list" rel="nofollow">

Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: