Re: [netconf] Create IANA-defined modules?

Kent Watsen <> Thu, 03 June 2021 02:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 60F733A24FE for <>; Wed, 2 Jun 2021 19:25:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.893
X-Spam-Status: No, score=-1.893 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_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 9_nyEatDJ1TK for <>; Wed, 2 Jun 2021 19:25:24 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7CFB73A2502 for <>; Wed, 2 Jun 2021 19:25:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug;; t=1622687123; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=n+6mh/VUH6Tg9IWQJvBoTopJdsfxI8LNAqVRHB9rh5s=; b=flGS6sIcM/zJNf024GB1CYSF1ZCS7CE5BhvxLWM2kzltA82ayeRxR0+c++z7ndKd f2OuGNboM2me+J5WL0LBbU+/m2tWv6dyGU0yu/m2l/sD6RdflGoz/fFdANKrSSrXaxq JfVbzTrUr4ucgDhzGcyvkmGOup0otScoDdH3onqw=
From: Kent Watsen <>
Message-ID: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_537A74C5-7724-42FF-8F52-304E23144B69"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
Date: Thu, 3 Jun 2021 02:25:23 +0000
In-Reply-To: <>
To: "" <>
References: <> <>
X-Mailer: Apple Mail (2.3654.
X-SES-Outgoing: 2021.06.03-
Archived-At: <>
Subject: Re: [netconf] Create IANA-defined modules?
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: Thu, 03 Jun 2021 02:25:30 -0000

I’ve been looking at this change (since no one volunteered to help :sigh:) and noticed that Gary had feature statements for optional-to-implement algorithms.  

When we were doing the now-abandoned “algorithms” work in crypto-types, we defined a top-level “config false” tree for a list of supported algorithms.  For instance, see "supported-symmetric-algorithms” here:  This seems better to me, agreed?  Would an RPC be better than a "config false" tree?

Does it matter if the algorithms are defined using an enumeration or as an identity?

Gary defined them as identities, but the abandoned crypto-types work had them as enumerations.  In either case, the IANA-maintained module needs to be *implemented* - thoughts?

Note: if “identity” statements are used, and the module is *implemented* (for the top-level “supported algorithms” data tree) does NOT mean the server supports all the algorithms, which is true only if the algorithm appears in the “supported algorithms” list - still makes sense, or is this a compelling reason to NOT use identities?

PS: putting each algorithm into its own module that can be distinctly “implemented* is a non-starter.


> On May 26, 2021, at 9:40 PM, Gary Wu (garywu) <> wrote:
> Hi Kent,
> I'm out of the loop with the happenings in the WG, so apologies in advance if
> my views are ill-informed.
> The IANA maintained module for parameters makes good sense to me.
> The if-features are less important than being able to configure or unconfigure
> which ciphers are able to be used, so if one has to go, it should be the former.
> Presumably, administrators are making security considerations based on sources
> other than just what the YANG module has defined.
> Thanks,
> Gary
> On 5/26/21, 12:05 PM, "Kent Watsen" <> wrote:
>    [CC-ing Gary, who contributed the “ietf-[tls/ssh]-common" modules originally]
>    The “tls-client-server” draft just received the following GitHub “issue”:
>    =====start=====
>    This is rather a question than an issue, maybe.
>    Given that IANA maintains the TLS parameters at, would it not be better for that content to come from something like iana-tls[-parameters].yang rather than an IETF maintained YANG module?
>    =====stop=====
>    This is a good point.  Perhaps we should move all the identities for the algorithms defined in the “ietf-tls-common” module to an IANA-maintained “iana-tls-parameters” module.  Thoughts?
>    By extension, the same statement applies to the “ssh-client-server” draft and the IANA maintained SSH parameters page:
>    One potential issue with doing this is that the existing identities have “if-feature” statements that constrain them to specific TLS-versions and algorithm-families, and are sometimes marked as “deprecated".  By example:
>        identity ecdhe-ecdsa-with-aes-128-cbc-sha256 {
>           if-feature "tls-1_2";
>           if-feature "tls-ecc and tls-sha2";
>           base cipher-suite-base;
>           status "deprecated";
>           description
>               "Cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256.";
>           reference
>              "RFC 5289: TLS Elliptic Curve Cipher Suites with
>                                 SHA-256/384 and AES Galois Counter Mode (GCM)";
>        }
>    But that information is NOT captured in the IANA-maintained page.   What to do?
>    One option would be to drop all the feature statements.  All they do is limit the totality of algorithms presented to an administrator, when configuring which algorithms the client/server should support.  Worst case, all algorithms (of a given type) are presented, regardless if supported by the, e.g., TLS protocol version.  When configuring clients/servers using, e.g., text-based configuration files, such filters are never available.  Does anyone know what Cisco/Juniper/etc. devices do in their command-line and/or web interfaces?
>    Another option, which I like because it’s less work for me (unless someone can volunteer a GitHub pull request), is to remove the ietf-[tls/ssh]-common modules altogether.  They’re currently optional-to-configure and, when not configured, it’s an implementation-specific decision what, e.g., algorithms to list as being supported during the protocol handshake.  Personally, I’ve never used them (or implemented support for them), happily deferring to internal code and underlying libraries.  In lieu of us not defining these modules now, applications could augment-in their own configuration nodes and, of course, a future WG effort could add them.  Thoughts on this approach?
>    K.