Re: [netconf] Supported algorithms lists

"Salz, Rich" <> Mon, 17 February 2020 23:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2B889120048 for <>; Mon, 17 Feb 2020 15:24:20 -0800 (PST)
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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IwV8L6J29vZz for <>; Mon, 17 Feb 2020 15:24:17 -0800 (PST)
Received: from ( [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 84153120041 for <>; Mon, 17 Feb 2020 15:24:17 -0800 (PST)
Received: from pps.filterd ( []) by ( with SMTP id 01HNFF5x031932; Mon, 17 Feb 2020 23:24:17 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=U0wSebWDiv07LtB85M3CdHDrmLkPx29e0J17PFpq4qI=; b=W6mS0j5T9PAo+x+sxWx600GaSQi4/hbgv3d+7slLjcT+UjiR2d2nxoGqxSh8n2z9B4ZQ 4nVvxBZ1FAkJ4KbaqXAUbAT41ujbOe43U0lIvWYaxmIiUqBE1uAoXkpP4GNQPQoWdo62 6Z6VFbYWAncNwBgSULchjVjV62rCUVEf0rAP1aH8mq2ncKCq2XYXsWVdXb3vHiiW5Y4y YCgX+kPxgd3cUUxEV1dd3eOjJ8XumHM8bIblMUXH4Yfz+s0SfuuH8wcrwBrhAo6hbfRU sfjPBZuF4wIcKUfmB+zSbOHhYHEdk44QFQBrWe1zXl2Lqxt3Fjq/FnB4nqEHUA+7s/yY qQ==
Received: from prod-mail-ppoint2 ( [] (may be forged)) by with ESMTP id 2y6yeg6quf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 17 Feb 2020 23:24:17 +0000
Received: from pps.filterd ( []) by ( with SMTP id 01HNHVCZ022901; Mon, 17 Feb 2020 18:24:15 -0500
Received: from ([]) by with ESMTP id 2y6cv072rh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 17 Feb 2020 18:24:15 -0500
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 17 Feb 2020 18:24:14 -0500
Received: from ([]) by ([]) with mapi id 15.00.1473.005; Mon, 17 Feb 2020 18:24:14 -0500
From: "Salz, Rich" <>
To: Kent Watsen <>
CC: "" <>
Thread-Topic: [netconf] Supported algorithms lists
Thread-Index: AQHV4pJRGz8wjkufPEeULUGrOkBPq6gZdz2AgAC9VwCABipOAP//rrOA
Date: Mon, 17 Feb 2020 23:24:13 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_A6BFFEFD57D843EDBA3F1D9B872C2FEEakamaicom_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-02-17_14:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2002050000 definitions=main-2002170191
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-02-17_14:2020-02-17, 2020-02-17 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 spamscore=0 priorityscore=1501 impostorscore=0 malwarescore=0 adultscore=0 phishscore=0 mlxscore=0 clxscore=1015 lowpriorityscore=0 mlxlogscore=999 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2001150001 definitions=main-2002170191
Archived-At: <>
Subject: Re: [netconf] Supported algorithms lists
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: Mon, 17 Feb 2020 23:24:20 -0000

Looking forwards to reading the new docs.

From: Kent Watsen <>
Date: Monday, February 17, 2020 at 6:17 PM
To: Rich Salz <>
Cc: "" <>
Subject: Re: [netconf] Supported algorithms lists


TL;RD;, I’m back to thinking that the RPCs are best.

See below for an addendum.

Kent  // contributor

On Feb 13, 2020, at 8:06 PM, Kent Watsen <<>> wrote:

Hi Rich,  good to see you’re keeping us honest here ;)

it suggests a 3rd idea, which is to have an RPC that takes an XPath (to a key) and returns the list of supported algorithms for that key.

I could be confused, but I don't know if this is a good idea.  Suppose I have an RSA keypair; would I expect to get back every TLS 1.2 ciphersuite name that has RSA in it?  There are around 30.  And for TLS 1.3, where the identity is broken out separately from the bulk encryption -- the so-called "a la carte" approach -- it becomes rather difficult.

That’s not quite what I had envisioned, but you may be onto something nonetheless.

Regarding the proposed idea, first note that the intent is that the desire to know what algorithms are supported is mostly to either 1) ask the device to generate and key or 2) know what kind of key could be generated offline and subsequently loaded onto the device.  In either case, it’s not so much that you *have* an RSA keypair, but that you wish to generate a one.

To give a concrete example, assume the data model illustrated by tree diagram here:<>Ch6z1LwyHCwwExSGRlM&e=>.  The RPC might be:

 <rpc message-id="101"
     <get-supported-algorithms xmlns="urn:ietf:params:xml:ns:yang:ietf-crypto-types>

So it’s clear that the intent that the key is intended for TLS (not SSH).  That said, and to your point, it doesn’t indicate if for TLS 1.2 or 1.3 and, worse, if the path instead references a keystore path (e.g., /keystore/asymmetric-keys/asymmetic-key/…), it’s not even clear that the key is intended for TLS or SSH…

Regarding the algorithms being protocol sensitive (e.g., 1.2 vs 1.3), in lieu of not finding a way to do this in CLI, this appears to be a non-issue.

Regarding XPaths pointing to keys in Keystore, we need only declare them as unsupported (i.e., an error should be returned).  While the key MAY be configured to Keystore, the important part is to know where it is *used* (i.e., the XPath would be to a leafref pointing to the Keystore elsewhere in the configuration, per the original response above).

Note that misconfigurations are still possible.  For instance, someone could point a leafref to an already created yet incompatible key in the keystore.  It is expected that errors arising from such incompatibilities would be detected when the configuration is applied/committed.

PS: I’m preparing a multi-draft update that will include this idea (and every other discussed since IETF 106).  This update will most likely be used for the first WGLC on the three foundational client-server suite of drafts (i.e., crypto-types, keystore, and truststore).  So, if any objections, please shout out now.

Kent // contributor

In contrast, the current/planned/old approach described in my previous message, whereby there would be a list per protocol (TLS vs SSH), also did not take into account protocol versions (1.2 vs 1.3).  So, if this is an issue, we have no proposal addressing it yet...

How does OpenSSL CLI support this?  Looking at `openssl ciphers`, I see that it’s possible to specific protocol versions (i.e., 1.2, 1.3, etc.).   But, in the end, these are cipher suites (e.g., ECDHE-RSA-AES128-GCM-SHA256), not just the algorithm (RSA) and definitely not indicating supported key lengths (presumable all RSA key lengths are supported?)...

It would help if we could identify the CLI-equivalent for all this…

PS: both the SSH and TLS client-server draft create mapping tables between the protocol-specific cipher-suite names and to the algorithm names in crypto-types.  For instance, here are the mapping tables for TLS:<>WTO5wYeckXF_AUDpa9s&e=>.

PPS: I’m beginning to think that we might be better giving up on having any RPC to ask the server to generate keys or indicate which algorithms are supported, punting all this complexity to some future revision.  That said, it would be best is we could get something passable working now, if possible...

Kent. // contributor

netconf mailing list<>