Re: [netconf] Supported algorithms lists

Kent Watsen <> Fri, 14 February 2020 01:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5BA2C12003F for <>; Thu, 13 Feb 2020 17:06:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 PKwszYwPzMeM for <>; Thu, 13 Feb 2020 17:06:16 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 09A7F120020 for <>; Thu, 13 Feb 2020 17:06:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw;; t=1581642374; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=mfJ1dUm5L3Hv+1IBm5zHn0v6ae1t21MtOIihQ2bRxgE=; b=Jbq5bBxa8DLzLVsbmomdxJIqE+9ntl0IxBtFpMnGECygzFgwwRyMMUz+/X0mA8nF QsEIHrsTY9jR27tXgW0KL8/M+Qtg+a/GS3pEewddHRCjv5S4RDw0kQDfz0P3ZIS2pD7 wi3dRobyPnUVIAODkJRFACqF2ar82HtfOgOaScbQ=
From: Kent Watsen <>
Message-ID: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_EA6944BC-59A8-4098-B49A-F778519D958F"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Fri, 14 Feb 2020 01:06:14 +0000
In-Reply-To: <>
Cc: "" <>
To: "Salz, Rich" <>
References: <> <>
X-Mailer: Apple Mail (2.3445.104.11)
X-SES-Outgoing: 2020.02.14-
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: Fri, 14 Feb 2020 01:06:18 -0000

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: <>.  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…

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:

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