Subject: Re: [netconf] Create IANA-defined modules?

From: Kent Watsen <[email-masked]>
Date: Thu, 3 Jun 2021 02:25:23 +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:  https://datatracker.ietf.org/doc/html/draft-ietf-netconf-crypto-types-14#appendix-A.1.  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.

K.

> On May 26, 2021, at 9:40 PM, Gary Wu (garywu) <[email-masked]> 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" <[email-masked]> wrote:
> 
>    [CC-ing Gary, who contributed the “ietf-[tls/ssh]-common" modules originally]
> 
> 
>    NETCONF WG,
> 
>    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   https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml, 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: https://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml.
> 
>    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.
> 
> 
> 
>

---

From: tom petch <[email-masked]>
Date: Thu, 10 Jun 2021 09:52:29 +0000

Mmmm this is getting ever more tangled but let me see if I can get my comments through the Internet police:-)
 
Qin Wu <[email-masked]>| Wed, 09 June 2021 13:07 UTC
发件人: netconf [mailto:[email-masked]] 代表 Kent Watsen
发送时间: 2021年5月27日 3:06
收件人: [email-masked]

NETCONF WG,

=====start=====

[Qin]: I agree this seems straightforward to me. The module name could be "iana-tls-types" like.

<tp> except that that name makes it look like the work of the TLS WG which it should be but it not.

[Qin]: Why not bind tls version with cipher-suite in the ecdhe-ecdsa-with-aes-128-cbc-sha256 identity definition. Also I feel identity name is too long.

<tp>  The TLS WG defined and named the cipher suite and that is the name they gave it.  Use something else and no one familiar with TLS will know what it is.

[Qin]: See above, do we need to introduce if-feature "tls-1_2" and why not tie the tls version in the cipher-suite name such as "tls12-ecdhe-ecdsa-with-aes-128-cbc-sha256". 

<tp> Again, the TLS WG designed and named the cipher suites and they are intended to be version neutral.  Look at the IANA registry, dozens of them, all TLS_  call them something different and no one familiar with TLS will know what you are talking about.  The choice of the name was made by the TLS WG and it would be wrong of the Netconf WG to seek to improve it after all these decades.  You might argue that encoding all the semantics in the name was a poor choice but if so, adding more semantics is not an improvement

Tom Petch

K.

________________________________________
From: netconf <[email-masked]> on behalf of Kent Watsen <[email-masked]>
Sent: 03 June 2021 03:25
To: [email-masked]
Subject: Re: [netconf] Create IANA-defined modules?

K.

---

From: "Per Andersson (perander)" <[email-masked]>
Date: Thu, 10 Jun 2021 21:36:46 +0000

> 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-algori…

Having it as a "config false" tree would make it possible to use
e.g. must or when expressions towards that tree if one would
want. Which is better IMHO.

--
Per

---

From: Kent Watsen <[email-masked]>
Date: Mon, 14 Jun 2021 16:22:14 +0000

Thank you Qin, Tom, and Per for the responses to my last post…this message addresses them all.

Since the discussion has been mostly about *how* to create the IANA-defined module (not *if* we should, e.g., dropping the work for some future effort to pickup), I take it that folks believe having the ability for configure supported-algorithms is needed now.  As no one offered to help (:sigh:, and people wonder why this work takes so long), I wrote the attached script that creates the attached module directly from the data obtained from the IANA-maintained "TLS Cipher Suites" sub-registry of the "Transport Layer Security (TLS) Parameters” registry here: https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml.  The resulting module is also attached.  

Tom, you will be happy to know that the all the identity names begin with “tls”  :)    Also, there are no “feature” statements, since there is nothing in the source registry that can be used to generate “if-feature” statements.  Out of the 347 algorithms listed in the registry,  310 algorithms are marked “status deprecated” (driven by the “recommended” column having value ’N’), and 7 algorithms are marked “status obsolete” (driven by the "SC-tls-des-idea-ciphers-to-historic” reference).

Regarding if to use a  “config false” tree or an RPC, Per makes an interesting point about “must" and “when” expressions, though I do wonder how that would play out in practice, as said expressions would (presumably) be defined under “config true” nodes and hence couldn't reference the “config false” values?  Maybe Per could say some more about the use-case in mind.

No one responded regarding if we should use identities or enumerations.  The attached sample module uses identities, but it would be an easy thing to change the script to generated enumerations - thoughts?

Again: if “identity” statements are used, and the module is *implemented*, it would NOT mean the server supports all (or even any) of the algorithms. This would only be known if the algorithm appears in the “supported algorithms” "config false” list.  Does anyone feel this is a misuse of YANG?  IMO, YANG identities needing to be implemented is not very useful in practice, and so I don’t view that as a negative in the slightest.

K.

---

From: "Per Andersson (perander)" <[email-masked]>
Date: Mon, 14 Jun 2021 17:58:38 +0000

> Tom, you will be happy to know that the all the identity names begin with “tls”  :)    Also, there are no “feature” statements, since there is nothing in the source registry that can be used to gen…

I was on the brink to volunteer, sorry that I didn't raise my voice in time.
Good work, nonetheless.

> Regarding if to use a  “config false” tree or an RPC, Per makes an interesting point about “must" and “when” expressions, though I do wonder how that would play out in practice, as said expressions…

I saw a use case where some subset of the configuration tree
(e.g. a list of devices or restconf/netconf tls servers) could have
a schema when expression depending on the server's supported
algorithms.

However, I did not think it through that they were config nodes that
were going to access non-config nodes.

> Again: if “identity” statements are used, and the module is *implemented*, it would NOT mean the server supports all (or even any) of the algorithms. This would only be known if the algorithm appea…

AFAICS identities and enumerations support the same set of
sub-statements .

Using identities it would be possible to derive them from
other identities, and by doing so encode some more
information (e.g. is it a symmetric or asymmetric key etc).
This could hold some value.

>From reading RFC 7950, it looks to me like identities are
much like atoms or named constants; their existance in
an implemented module does not imply or guarantee any
working (code/server) implementation. (Correct me if I'm
wrong here.)

I think identities should be used.

--
Per