Subject: [netconf] IANA templates for algorithms

From: Kent Watsen <[email-masked]>
Date: Wed, 19 Feb 2020 00:21:11 +0000

From our session at IETF 106, there was a suggestion to follow the “template” pattern forged by draft-ietf-dnsop-iana-class-type-yang, which provides an XSLT script that generates a YANG module by processing as input the XML for the separately maintained "DNS Parameters” registry, specifically https://www.iana.org/assignments/dns-parameters/dns-parameters.xml.  The IANA workflow is:

    1) whenever updating the DNS Parameters registry...
            - for whatever RFC may be requesting it

    2) also update the YANG module...
            - by re-running the XSLT script again over the updated XML file

The prerequisite for this process is that there exists separate registries to pull data from, i.e., the input to the XSLT script.  The closest comparable registries that we could pull from seem to be:

 - for TLS: https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml
 - for SSH: https://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml

Neither of these registries help us, at least not directly.  Yes, they provide enumerations for on-the-wire protocol values, but they fail to provide an enumeration for, e.g., a 2048-bit RSA key.

Keying off Rob’s comment from the 106 meeting for the IANA process to engage expert reviewers, it seems that a process akin to the following is needed:

    1) whenever some number of existing target registries are updated
          - for now, just the SSH/TLS registries listed above

    2) engage an "expert reviewer" to see if any of the new entries
        regard an undefined algorithm and, if so, a TBD process is
        used to add the new algorithms to the appropriate YANG
        module (e.g., iana-symmetric-algorithms), which would be
        automatically published by IANA.

Drilling into step (2) some, the process might actually be:

  2a) update some new TBD registry (e.g., “base algorithms”).
        This would need to be done by a crypto expert (not the
        NETCONF WG or YANG Doctors.  Good candidates might
        the Security ADs or, perhaps better, the WG that published
        the source RFC.

  2b) run a script over the updated new TBD “base algorithms” 
         registry to produce the desired updated YANG module(s).  
         Presumably IANA could do this in the same way as will
         Be done for the DNS Parameters registry.

Obviously (2a) relies heavily on buy-in from the Security Area experts.  The buy-in needs to be both that this is an important registry to define and support the publication of an RFC that creates and defines rules for maintaining said registry.   Our “crypto-types” draft could be this RFC, if they’re okay with that.

Rich, as someone more connected to the Security Area, what do you think about this plan and any ideas on how to proceed to get the needed buy-in?

Kent // contributor

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 19 Feb 2020 01:06:18 +0000

>    Neither of these registries help us, at least not directly.  Yes, they provide enumerations for on-the-wire protocol values, but they fail to provide an enumeration for, e.g., a 2048-bit RSA key.
  
Yes, RSA size is not relevant to the protocols.

By undefined, you mean "unknown to YANG" I assume, and not "a new crypto alg not previously used in TlS (for example)."

            This would need to be done by a crypto expert (not the
            NETCONF WG or YANG Doctors.  Good candidates might
            the Security ADs or, perhaps better, the WG that published
            the source RFC.
I don't know if the sec folks would be interested in this but I could be wrong.  It might be good to have a brief chat F2F in Vancouver, which I can help set up.

---

From: Kent Watsen <[email-masked]>
Date: Wed, 19 Feb 2020 03:37:41 +0000

Hi Rich,

> Yes, RSA size is not relevant to the protocols.

Not to TLS, but I think that size may be relevant to SSH.  For instance, RFC 4432 defines both "rsa1024-sha” and "rsa2048-sha256”.   But these enumerations are for ciphers (i.e., more than we need/want to generate a key).

FWIW, `ssh-keygen` has the “-b bits” parameter and `openssl genrsa` has the “[numbits]” parameter.   The SSH/TLS protocols don’t define how the keys are created (it's out-of-scope to those drafts), hence why their registries don’t need to define enumerations for the base algorithms.

Of course, it is our goal to enable the configuration/generation of the keys themselves; effectively mimicking the CLI commands

> By undefined, you mean "unknown to YANG" I assume, and not "a new crypto alg not previously used in TLS (for example).”

Yes, unknown to the YANG modules that we’re trying to define, but also unknown to the TBD “base algorithms” registry mentioned in (2a) below.

>            NETCONF WG or YANG Doctors).  Good candidates might
>            be the Security ADs or, perhaps better, the WG that published
>            the source RFC.
> 

That would be great!  FWIW, I’m on good terms with Ben Kaduk, Sean Turner, and Russ Housley, but maybe you were thinking SecDir?  Would it be good prepare something (e.g., slides) to help explain it?  IDK, it seems easy enough to just talk to, but that’s just my POV.

Regading “interest", do you mean in terms of a) acknowledging it’s a problem, b) supporting the creation of a registry, c) participating in the creation of the registry, or d) maintaining the registry (the expert reviews)?   The minimal would be (a+b), so our attempt to do (c) isn’t torpedoed by SecDir/IESG.  For (d), it would be best if they could assign an expert reviewer (perhaps SecDir), as the prospect of (presumably) just me doing it doesn’t seem right...

Kent // contributor

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 19 Feb 2020 03:51:48 +0000

I spoke about this at secdir awhile ago and folks were not enthusiastic about the efforts here.

I would reach out to Ben and ask for time at the open area, SAAG.

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 19 Feb 2020 09:55:31 +0100

>             - by re-running the XSLT script again over the updated XML file

Strictly speaking, the XSLT stylesheet is still intended only for producing the initial revision of the module.

Re-running the stylesheet on a later revision of the registry would essentially work, only the revision history would be lost. I don't see any easy workaround to this.

It is up to IANA (we can help them) to decide whether the YANG module will be updated as before, e.g. by manually adding new enums, identities etc., or whether they use the stylesheet and then manually edit the revision history.

Maybe it would be useful to write an informational RFC suggesting a workflow for these cases.

Lada

> _______________________________________________
> netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

-- 
Ladislav Lhotka 
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

---

From: Kent Watsen <[email-masked]>
Date: Wed, 19 Feb 2020 11:59:16 +0000

Hi Lada,

> Strictly speaking, the XSLT stylesheet is still intended only for producing the initial revision of the module.

Apparently  my expectations got ahead of me.

> Re-running the stylesheet on a later revision of the registry would essentially work, only the revision history would be lost. I don't see any easy workaround to this.

Perhaps pass the YIN of the “current” YANG module into the XSLT script too?

> It is up to IANA (we can help them) to decide whether the YANG module will be updated as before, e.g. by manually adding new enums, identities etc., or whether they use the stylesheet and then manu…

But it’s still a manual YANG-editor level effort, which is new (I assume) to IANA.

> Maybe it would be useful to write an informational RFC suggesting a workflow for these cases.

Don’t think that there is a patten just yet.  Your draft’s use XSLT to create the initial revision makes sense only in that the registry already exists and new registrations may occur while your draft is being published.  

In crypto-type's case, the intention is to create a brand new registry/YANG-module, so we could just as easily put the initial YANG module into the draft, negating the need for IANA to run `xsltproc` at all.

If IANA doesn’t run XSLT for subsequent updates, I think that we (NETCONF) need to question if a registry is even needed.   The motives behind defining a registry are 1) to accommodate IANA and 2) to make it seem more official/interesting to the Sec folks (since “YANG” appears to be uncool/taboo?).  But if IANA is okay editing the YANG, and the Sec folks are still uninterested, then we could skip creating the registry altogether.

That said, I feel that creating a, e.g., “base algorithms” registry is best, as it allows for potential future/other use cases, and I’m hopeful/optimistic that we can get the Sec folks onboard.

Kent // contributor

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 19 Feb 2020 13:57:16 +0100

> Apparently  my expectations got ahead of me.

This solved the objections raised in the DNSOP WG, and I don't want to harass
them with any more complications. :^) 

> 
> 
> > Re-running the stylesheet on a later revision of the registry would
> > essentially work, only the revision history would be lost. I don't see any
> > easy workaround to this.
> 

Yeah, but this is already not exactly straightforward. 

> 
> > It is up to IANA (we can help them) to decide whether the YANG module will
> > be updated as before, e.g. by manually adding new enums, identities etc., or
> > whether they use the stylesheet and then manually edit the revision history.
> 

I assume they do manual editing of modules like "iana-if-type" when rolling out
a new revision.

> Don’t think that there is a patten just yet.  Your draft’s use XSLT to create
> the initial revision makes sense only in that the registry already exists and 

Yes, this is intended for mapping existing registries to YANG in a 1-1 fashion.

> new registrations may occur while your draft is being published.

The main concern of some DNSOP people was that the RFC itself is not updated, so
somebody can use the obsolete module contained therein any time later. If they
do it with the XSLT stylesheet, they should get basically the current data.

>  
> 
> In crypto-type's case, the intention is to create a brand new registry/YANG-
> module, so we could just as easily put the initial YANG module into the draft,
> negating the need for IANA to run `xsltproc` at all.

Then the YANG module effectively becomes the registry. It is a different problem
though.

> 
> If IANA doesn’t run XSLT for subsequent updates, I think that we (NETCONF)
> need to question if a registry is even needed.   The motives behind defining a

This is of course a rather NETCONF/YANG-centric view. There are people who don't
give a damn to YANG and NETCONF, but still need a registry. 

> registry are 1) to accommodate IANA and 2) to make it seem more
> official/interesting to the Sec folks (since “YANG” appears to be
> uncool/taboo?).  But if IANA is okay editing the YANG, and the Sec folks are
> still uninterested, then we could skip creating the registry altogether.

Yes, but then somebody will have to take care about maintaining the module. I
think that NETCONF isn't the right place for it, and sec folks may not be
interested.

Lada

> 
> That said, I feel that creating a, e.g., “base algorithms” registry is best,
> as it allows for potential future/other use cases, and I’m hopeful/optimistic
> that we can get the Sec folks onboard.
> 
> 
> Kent // contributor
> 
>