Subject: [netconf] I-D Action: draft-ietf-netconf-crypto-types-09.txt

From: [email-masked]
Date: Thu, 20 Jun 2019 07:52:48 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Configuration WG of the IETF.

        Title           : Common YANG Data Types for Cryptography
        Authors         : Kent Watsen
                          Wang Haiguang
	Filename        : draft-ietf-netconf-crypto-types-09.txt
	Pages           : 56
	Date            : 2019-06-20

Abstract:
   This document defines YANG identities, typedefs, the groupings useful
   for cryptographic applications.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netconf-crypto-types/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netconf-crypto-types-09
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-crypto-types-09

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-crypto-types-09

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Kent Watsen <[email-masked]>
Date: Thu, 20 Jun 2019 15:44:07 +0000

This update converts the algorithms from being identities to enumerations.

This is suppose to be the result from the thread started on April 25 entitled "The maintenance of the algorithm identifiers in draft-ietf-crypto-types" but, actually, I think it's from an earlier thread in which I believe Lada stated rationale for using enumerations instead of identities (I can't find that thread right now).   Seeing that the enum "values" are just in position-order, I'm unsure what issue this change resolves, but it seems nicer that a server doesn't have to *implement* the module, and also the values don't have to be prefixed...

All said, I think that the maintainability issue remains.  IIRC, Tom Petch suggestion breaking the algorithms into smaller modules, that is, one module per what is now an "enumeration", and also I think that there was a recommendation for making these "iana-" modules...

This change is orthogonal to the update posted three days ago, which focused on how to support server-generated keys, etc.  No objections have been received so far, and thus I'm beginning to think it's okay and we can go into last call after the above discussion resolves.

Kent // contributor

> On Jun 20, 2019, at 10:52 AM, [email-masked] wrote:
> 
> 
> _______________________________________________
> netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: "Xialiang (Frank, Network Standard & Patent Dept)" <[email-masked]>
Date: Mon, 24 Jun 2019 02:28:03 +0000

Hi Kent and all,
Please see my comments inline:

发件人: netconf [mailto:[email-masked]] 代表 Kent Watsen
发送时间: 2019年6月20日 23:44
收件人: [email-masked]
主题: Re: [netconf] I-D Action: draft-ietf-netconf-crypto-types-09.txt

This is suppose to be the result from the thread started on April 25 entitled "The maintenance of the algorithm identifiers in draft-ietf-crypto-types" but, actually, I think it's from an earlier thread in which I believe Lada stated rationale for using enumerations instead of identities (I can't find that thread right now).   Seeing that the enum "values" are just in position-order, I'm unsure what issue this change resolves, but it seems nicer that a server doesn't have to *implement* the module, and also the values don't have to be prefixed...
[Frank]: FYI, the earlier thread discussing and proposing a good solution for currently using enumerations instead of identities is: https://mailarchive.ietf.org/arch/msg/i2nsf/CKUsox3ua9JitEb5pQMN8-Iogwg   (Thanks Lada, Mahesh, Juergen, Martin, Andy, Acee, Paul Wouters and etc. for the productive discussion). The next issue to be addressed is whether the enum “values” can be in position-order, or should be the same as their respective IANA defined crypto algorithm numbers? For the latter case, which IANA should they be aligned: TLS, IPSec or SSH?

All said, I think that the maintainability issue remains.  IIRC, Tom Petch suggestion breaking the algorithms into smaller modules, that is, one module per what is now an "enumeration", and also I think that there was a recommendation for making these "iana-" modules...
[Frank]: Should we define the YANG modules for crypto types in yang IANA page?

B.R.
Frank

Kent // contributor

On Jun 20, 2019, at 10:52 AM, [email-masked]<mailto:[email-masked]> wrote:

Abstract:

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

---

From: Wang Haiguang <[email-masked]>
Date: Mon, 24 Jun 2019 08:31:54 +0000

I am also have similar concern as Frank whether the values should be assigned by IANA or just use position order.

From a long term view, could the IANA assignment be a better choice?

Regards.

Haiguang

From: netconf [mailto:[email-masked]] On Behalf Of Xialiang (Frank, Network Standard & Patent Dept)
Sent: Monday, June 24, 2019 10:28 AM
To: Kent Watsen <[email-masked]>
Cc: [email-masked]
Subject: [netconf] 答复: I-D Action: draft-ietf-netconf-crypto-types-09.txt

Hi Kent and all,

发件人: netconf [mailto:[email-masked]] 代表 Kent Watsen
发送时间: 2019年6月20日 23:44
收件人: [email-masked]<mailto:[email-masked]>
主题: Re: [netconf] I-D Action: draft-ietf-netconf-crypto-types-09.txt

B.R.
Frank

Kent // contributor

Abstract:

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 24 Jun 2019 12:52:53 +0200 (CEST)

Hi,

Kent Watsen <[email-masked]> wrote:
> This is suppose to be the result from the thread started on April 25
> entitled "The maintenance of the algorithm identifiers in
> draft-ietf-crypto-types"

I read that thread, but it doesn't discuss identities vs. enumerations
at all.

> but, actually, I think it's from an earlier
> thread in which I believe Lada stated rationale for using enumerations
> instead of identities (I can't find that thread right now).

This is a pretty drastic change to this module, and it is based on a
discussion that you think have taken place, but can't find?

I think we need to first decide what these types are suppposed to be.
The current design with a union seems to indicate that the type is
either an alg registered by IANA or one of the enums (which then are
not registered by IANA...??):

     typedef hash-algorithm-t {
       type union {
         type uint16;
         type enumeration {
           enum NONE {
             value 0;
             description
               "Hash algorithm is NULL.";
           }
           enum sha1 { ... }
           ...
         }
       }
       description
         "The uint16 filed shall be set by individual protocol
          families according to the hash algorithm value assigned by
          IANA. ...";
     }

There are several issues here: there is no reference to the IANA
regsitry; enum NONE is questionable in configuration; the description
seems to be copy-and-pasted ("protcol families").

I think that the only reason for using an enumeration instead of an
identity is if we really want to lock down the possible values, which
can be ok, e.g., if the values MUST be values in an IANA registry.

> Seeing
> that the enum "values" are just in position-order, I'm unsure what
> issue this change resolves, but it seems nicer that a server doesn't
> have to *implement* the module, and also the values don't have to be
> prefixed...
> 
> All said, I think that the maintainability issue remains.  IIRC, Tom
> Petch suggestion breaking the algorithms into smaller modules, that
> is, one module per what is now an "enumeration", and also I think that
> there was a recommendation for making these "iana-" modules...

Yes, you probably want to make these modules reflect the IANA
registries, compare with the iftype registry.

> This change is orthogonal to the update posted three days ago, which
> focused on how to support server-generated keys, etc.  No objections
> have been received so far, and thus I'm beginning to think it's okay
> and we can go into last call after the above discussion resolves.

I haven't checked this yet, but will do so now.

/martin

---

From: "Xialiang (Frank, Network Standard & Patent Dept)" <[email-masked]>
Date: Mon, 24 Jun 2019 11:31:07 +0000

Hi Martin,
Please see my last email about the previous discussion background for this change: https://mailarchive.ietf.org/arch/msg/netconf/pRkvMr0mTkYW-GLDAeN3Csg0gY4

Thanks!

B.R.
Frank

-----邮件原件-----
发件人: netconf [mailto:[email-masked]] 代表 Martin Bjorklund
发送时间: 2019年6月24日 18:53
收件人: [email-masked]
抄送: [email-masked]
主题: Re: [netconf] I-D Action: draft-ietf-netconf-crypto-types-09.txt

Hi,

> entitled "The maintenance of the algorithm identifiers in 

I read that thread, but it doesn't discuss identities vs. enumerations at all.

> but, actually, I think it's from an earlier thread in which I believe 
> Lada stated rationale for using enumerations instead of identities (I 
> can't find that thread right now).

This is a pretty drastic change to this module, and it is based on a discussion that you think have taken place, but can't find?

I think we need to first decide what these types are suppposed to be.
The current design with a union seems to indicate that the type is either an alg registered by IANA or one of the enums (which then are not registered by IANA...??):

There are several issues here: there is no reference to the IANA regsitry; enum NONE is questionable in configuration; the description seems to be copy-and-pasted ("protcol families").

I think that the only reason for using an enumeration instead of an identity is if we really want to lock down the possible values, which can be ok, e.g., if the values MUST be values in an IANA registry.

> there was a recommendation for making these "iana-" modules...

Yes, you probably want to make these modules reflect the IANA registries, compare with the iftype registry.

/martin

> > Please note that it may take a couple of minutes from the time of 
> > submission until the htmlized version and diff are available at 
> > tools.ietf.org.
> >

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 24 Jun 2019 14:11:33 +0200 (CEST)

Hi,

"Xialiang (Frank, Network Standard & Patent Dept)" <[email-masked]> wrote:
> Hi Martin,
> Please see my last email about the previous discussion background for
> this change:
> https://mailarchive.ietf.org/arch/msg/netconf/pRkvMr0mTkYW-GLDAeN3Csg0gY4

Ok I have read this thread.  It talks about a number of problems.

Can you explain which problem is solved by this change?

/martin

---

From: Kent Watsen <[email-masked]>
Date: Mon, 24 Jun 2019 12:32:31 +0000

> discussion that you think have taken place, but can't find?

That could’ve been worded differently, but note that:

1) This part of the module is being developed by my co-author.  While I pushed the button to publish it, he is more involved and tracking details. 

2) I recall the thread occurring, but couldn’t find it in my local archive (likely due to the Juniper switch out) and the online search function is pretty weak.

Kent // contributor

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 24 Jun 2019 14:47:46 +0200 (CEST)

Kent Watsen <[email-masked]> wrote:
> 1) This part of the module is being developed by my co-author.  While
> I pushed the button to publish it, he is more involved and tracking
> details.
> 
> 2) I recall the thread occurring, but couldn’t find it in my local
> archive (likely due to the Juniper switch out) and the online search
> function is pretty weak.

Aha, ok that explains your text!

/martin

---

From: "Xialiang (Frank, Network Standard & Patent Dept)" <[email-masked]>
Date: Tue, 25 Jun 2019 00:44:53 +0000

Hi Martin,
The new union definition of crypto algorithms aims to provide the flexibility of:
1. the uint16 can be used to represent current and future IANA defined crypto algorithms in number;
2. the enumeration can be used to represent current IANA defined crypto algorithms with better readability, and should be aligned with their values (which we are figuring out). 

Actually, it is proposed by Ladislav Lhotka, and discussed in I2NSF mailing list for some time. And it way mentioned that the similar definition has already been used in https://tools.ietf.org/html/draft-lhotka-dnsop-iana-class-type-yang-01, and https://www.rfc-editor.org/rfc/rfc8294.txt.

B.R.
Frank

-----邮件原件-----
发件人: Martin Bjorklund [mailto:[email-masked]] 
发送时间: 2019年6月24日 20:12
收件人: Xialiang (Frank, Network Standard & Patent Dept) <[email-masked]>
抄送: [email-masked]; [email-masked]
主题: Re: 答复: [netconf] I-D Action: draft-ietf-netconf-crypto-types-09.txt

Hi,

/martin

> > but, actually, I think it's from an earlier thread in which I 
> > believe Lada stated rationale for using enumerations instead of 
> > identities (I can't find that thread right now).
> 
> > is, one module per what is now an "enumeration", and also I think 
> > that there was a recommendation for making these "iana-" modules...
> 
> > > https://datatracker.ietf.org/doc/html/draft-ietf-netconf-crypto-ty
> > > pe
> > > s-09
> > >

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 25 Jun 2019 08:45:08 +0200 (CEST)

Hi,

"Xialiang (Frank, Network Standard & Patent Dept)" <[email-masked]> wrote:
> 2. the enumeration can be used to represent current IANA defined
>    crypto algorithms with better readability, and should be aligned with
>    their values (which we are figuring out).

If you "only" want to represent an IANA-maintained registry, you can
create an IANA-maintained YANG module with the enums from that
registry.  That YANG module will by definition always be up to date.
No need to handle integers for this.

Or, if you want extensibility, you can use the approach that we used
in the "iana-if-type" YANG module with identities.

> Actually, it is proposed by Ladislav Lhotka, and discussed in I2NSF
> mailing list for some time. And it way mentioned that the similar
> definition has already been used in
> https://tools.ietf.org/html/draft-lhotka-dnsop-iana-class-type-yang-01,
> and https://www.rfc-editor.org/rfc/rfc8294.txt.

I believe this use case is a bit different, or rather I don't think
there's a one-size-fits-all solution to this problem.

So, to start with, for each of the types in the crypto module, could
you specify the link to the corresponding IANA registry?

Also, the thread on the I2NSF ML started with this question:

  [our draft[ imports from draft-ietf-netconf-crypto-types, which
  appears to be a generic list of algorithms.

  The problem is that the list in draft-ietf-netconf-crypto-types
  could contain algorithms that are not suitable for IPsec (such as
  secp192r1 for key agreement), and right now it seems to lack some
  older algorithms that have fallen out of fashion (3DES) but is still
  needed in IPsec.

The solution you propose doesn't solve this problem.

(Perhaps it is not a coincident that IANA lists 15+ different hash
function registries, for various applications)

/martin

---

From: Kent Watsen <[email-masked]>
Date: Tue, 25 Jun 2019 16:20:17 +0000

> you specify the link to the corresponding IANA registry?

Yes, please send out the links so we have more clue...

To take a step back, my perception for how we got here is thus:

1) the keystore draft wishes to store keys (perhaps created at the time of manufacturing) that can subsequently be referenced by downstream models, such as in the SSH and TLS client/server drafts.

2) to support this goal, the crypto-types draft defined some types for keys (first as identities, now as enumerations).

3) crypto savvy folks wanted to embrace and extend the definitions in crypto-types to be more complete (i.e., more then just keys)

4) to enable the SSH and TLS models to use types defined in their protocol specs, mapping tables were added to those drafts to map the protocol-specific types to the generic crypto-types type.

5) the IPsec folks now have a similar problem, to which the answer might be to do the same as the SSH and TLS drafts (i.e., define mappings from IPSec-specific types to crypto-types types)

6) the general underlying issue is likely exasperated by the crypto-types draft defining more types than needed for just keys (i.e., the more it tries to support, the more mapping tables are needed), albeit this in itself seems like a good thing.

7) it's unclear to me where the root cause of the problem lies.  It seems that the crypto folks may have instigated this long ago, by creating overlapping definitions for identical algorithms, which then manifested in the form of multiple IANA registries.

8) our efforts to normalize this may be futile, and yet we want to support keystore.

Please correct any misstatements, as I'm speculating on some of the above.

Thinking out of the box, if we were to fold on crypto-types defining algorithms, perhaps keystore could store instances of something like an abstract base class that is subclassed by downstream modules (ssh, tls, ipsec).  The problem with this approach is that the keys become purpose-specific and so, e.g., if a device has a manufacturer-generated key, that key could only be used for the single purpose (e.g., TLS) and not for any other purpose (e.g., SSH, IPSec, etc.).  Sure, the vendor could create key multiple purpose-specific "keys" for the same underlying key store in hardware, but it would ultimately fail to support any purpose, potentially defined later in time.

Kent // contributor

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 25 Jun 2019 22:42:43 +0200 (CEST)

Hi,

Kent Watsen <[email-masked]> wrote:
> 1) the keystore draft wishes to store keys (perhaps created at the
> time of manufacturing) that can subsequently be referenced by
> downstream models, such as in the SSH and TLS client/server drafts.
>
> 2) to support this goal, the crypto-types draft defined some types for
> keys (first as identities, now as enumerations).
>
> 3) crypto savvy folks wanted to embrace and extend the definitions in
> crypto-types to be more complete (i.e., more then just keys)
> 
> 4) to enable the SSH and TLS models to use types defined in their
> protocol specs, mapping tables were added to those drafts to map the
> protocol-specific types to the generic crypto-types type.

So perhaps this is not the best solution?  The big set of types (in
crypto-types) will change over time, and the subsets used in various
applications will also change over time.  The best solution for such
sets in the IETF seems to be IANA registries, with corresponding
IANA-maintained YANG modules.

> 5) the IPsec folks now have a similar problem, to which the answer
> might be to do the same as the SSH and TLS drafts (i.e., define
> mappings from IPSec-specific types to crypto-types types)
> 
> 6) the general underlying issue is likely exasperated by the
> crypto-types draft defining more types than needed for just keys
> (i.e., the more it tries to support, the more mapping tables are
> needed), albeit this in itself seems like a good thing.
> 
> 7) it's unclear to me where the root cause of the problem lies.  It
> seems that the crypto folks may have instigated this long ago, by
> creating overlapping definitions for identical algorithms, which then
> manifested in the form of multiple IANA registries.
> 

Perhaps we can take a step back and define just the types we need
right now for keystore, in order to finish these drafts.  Then we (or
some other WG) can immediately start to work on an update to
crypto-types that would define more types for other purposes as well.

/martin

> Thinking out of the box, if we were to fold on crypto-types defining
> algorithms, perhaps keystore could store instances of something like
> an abstract base class that is subclassed by downstream modules (ssh,
> tls, ipsec).  The problem with this approach is that the keys become
> purpose-specific and so, e.g., if a device has a
> manufacturer-generated key, that key could only be used for the single
> purpose (e.g., TLS) and not for any other purpose (e.g., SSH, IPSec,
> etc.).  Sure, the vendor could create key multiple purpose-specific
> "keys" for the same underlying key store in hardware, but it would
> ultimately fail to support any purpose, potentially defined later in
> time.
> 
> Kent // contributor
>

---

From: Kent Watsen <[email-masked]>
Date: Thu, 27 Jun 2019 00:05:48 +0000

Hi Martin,

> IANA-maintained YANG modules.

I'm hoping someone, perhaps my co-authors, can suggest a path forward.

> crypto-types that would define more types for other purposes as well.

Maybe, depending on how that turns out, it may be trivial to extend the approach to cover everything.

Kent // contributor

---

From: "Xialiang (Frank, Network Standard & Patent Dept)" <[email-masked]>
Date: Thu, 27 Jun 2019 03:46:41 +0000

Hi Martin, Kent and all,
Thanks for so productive discussion and clarification for our current problems and possible solution. And sorry for late response since I am out of office yesterday.

Let me give more information for better understanding the difficulties we are facing, and hopeful a direction worth for going to.

Please see inline:

发件人: Kent Watsen [mailto:[email-masked]]
发送时间: 2019年6月27日 8:06
收件人: Martin Bjorklund <[email-masked]>
抄送: Xialiang (Frank, Network Standard & Patent Dept) <[email-masked]>; [email-masked]
主题: Re: [netconf] I-D Action: draft-ietf-netconf-crypto-types-09.txt

Hi Martin,

[Frank]: We mainly reference to these 3 IANA registries for define our crypto types in draft:

1.       https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml: which includes TLS 1.2 and TLS 1.3.

2.       https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml, https://tools.ietf.org/html/rfc8221-- crypto algorithms guidance for ESP and AH, https://tools.ietf.org/html/rfc8247-- crypto algorithms guidance for IKEv2: the 2 drafts are the latest recommendations for crypto algos of IPsec, so we mainly reference the definition in them;

3.       https://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml, https://tools.ietf.org/html/rfc4253 -- main SSH Spec, https://tools.ietf.org/html/rfc8332 -- new RSA with SHA256 and SHA512 for its authentication function: also, the 2 drafts are the main resource we have referenced.

So, the above reference are all current input for the crypto type definition in the crypto types draft. Now, the 2 main difficulties for us are:

1.       For the above 3 protocols and their respective and different crypto algorithm definition in each IANA registries, should we align our yang model to all of them, or only one of them? If the former, we must deal with the problem that same crypto algo has different IANA number in different IANA registries?

2.       Considering TLS 1.2, which uses a combined way to represent different types of crypto into one IANA number (e.g., TLS_DHE_RSA_WITH_AES_128_GCM_SHA256). That is against our crypto type definition principle (IPsec and SSH are all aligned): atomic, which means we are currently define 7 categories of crypto type: Hash Algorithms, Asymmetric Key Algorithms, MAC Algorithms, Encryption Algorithms, Encryption and MAC Algorithms, Signature Algorithms and Key Exchange Algorithms. So, how should we map our crypto type definition back to TLS 1.2 IANA numbers?

After clarifying our problems, I want to ask if we can solve them by this way: we yang guys define a crypto type yang IANA registries, which can keep on being aligned with all the related protocols’ IANA registries, but have its own IANA number for each crypto algorithms. So, our draft just need to follow this IANA registries.

8) our efforts to normalize this may be futile, and yet we want to
support keystore.

[Frank]: based on my clarification above, even we have TLS and SSH now, we still have to deal with the aforementioned 2 difficulties. If so, why not do it right at start time?

B.R.
Frank

Kent // contributor