[netconf] Supported algorithms lists

Kent Watsen <kent+ietf@watsen.net> Thu, 13 February 2020 17:23 UTC

Return-Path: <010001703f93981f-3ee1e05a-fa24-41c4-a168-f66af7d4176f-000000@amazonses.watsen.net>
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 B4E1E1200C4 for <netconf@ietfa.amsl.com>; Thu, 13 Feb 2020 09:23:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com
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 mAszmi0zlYdf for <netconf@ietfa.amsl.com>; Thu, 13 Feb 2020 09:23:24 -0800 (PST)
Received: from a48-93.smtp-out.amazonses.com (a48-93.smtp-out.amazonses.com [54.240.48.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2D92120058 for <netconf@ietf.org>; Thu, 13 Feb 2020 09:23:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1581614602; h=From:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Message-Id:Date:To:Feedback-ID; bh=NB1l0lvu4QEdtP0maDWXk1geDCG950a4gEwxVYLLcFs=; b=BBBM7HG3FmIXvqmWVld0qmQgf/4Oq+FHHGJorbVUXgyfr6Rnxt3uoLgMrplgisnY g+OL0aJ0wZ5gZe5J4KTleWA7VMBCVWyv9ANXsi1Sf5pk4xtUHM624rzENZt9D7HDaWj q53GT5NXFjnFgEanituyn5DGxNkGq9ctn803cN8Y=
From: Kent Watsen <kent+ietf@watsen.net>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Message-ID: <010001703f93981f-3ee1e05a-fa24-41c4-a168-f66af7d4176f-000000@email.amazonses.com>
Date: Thu, 13 Feb 2020 17:23:22 +0000
To: "netconf@ietf.org" <netconf@ietf.org>
X-Mailer: Apple Mail (2.3445.104.11)
X-SES-Outgoing: 2020.02.13-54.240.48.93
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/DrKxxHORYHpzJ_wCN-xkPC1Doko>
Subject: [netconf] Supported algorithms lists
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, 13 Feb 2020 17:23:26 -0000

All,

We had a discussion awhile back about split/move-ing the 3 “supported algorithm” lists into the SSH- and TLS- client-server drafts (a total of 6 lists when done).  The thinking was SSH and TLS might (perhaps likely?) support different algorithms, which would be good to capture.

That said, we noted that this was a compromise as there may be more than one SSH or TLS library used by an application, and thus having protocol-specific lists may be too  course (compared to library-specific lists).

I’m wondering if we can do better and maybe even simpler…

One idea is to stick with having a single list per algorithm type (i.e., symmetric, asymmetric, hash, etc.), but then to allow each list item to contain a list of *where* that algorithm can be used.   In the simplest case, the “where it can be used” could be enumerated values (“SSH”, “TLS”) but perhaps better could be a list of XPaths?

However this seems a bit upside-down, as what would likely be preferred is to have a list of XPaths and then, for each, as list of supported algorithms.     Better, but messy, but 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.

	rpc get-support-algorithms {
	   input {
	      leaf schema-path {
	         type string;
	         description
	            “Schema path to a ‘key’ node.”;
	      }
	   }
	   output {
	      choice key-type {
	         case symmetric-key {
	            leaf-list symmetric-algorithm {
                       type symmetric-algorithm-type;
                    }
	         }
	         case asymmetric-key {
	            leaf-list asymmetric-algorithm {
                       type symmetric-algorithm-type;
                    }
	         }
	      }
	   }
	}

This seems elegant as the implementation complexity scales with the complexity of the application.  An application that uses only a single crypto library could have a fairly static response, whereas complex applications could vary the response by the path (knowing which crypto library would be used).

Thoughts?

Kent // contributor