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

From: Wang Haiguang <[email-masked]>
Date: Wed, 3 Jul 2019 10:17:47 +0000

Hi， all.

I have some comments regarding the management of crypto algorithms used by different protocols such as TLS, IPSec and SSL.

At the moment, different work group maintains own definitions regarding the crypto algorithms, including public key algorithms, key exchange algorithms, hash, mac, encryptions etc.
Each working group defined their own identifiers for crypto algorithms. In some group, crypto algorithms for authentication, encryption and key exchange etc. are defined separately while others may combined identifiers.
The current method requires additional efforts in each group for protocol development, and also in implementation and network management.

A better way could be that the IETF security group define a unified crypto algorithm identifiers and register them with IANA. These crypto algorithm identifiers can be shared among  different working groups in their future work.
The current draft-ietf-crypto-types provides valuable work the classification of crypto algorithms.

I think we should discuss this point and make a decision whether we should get IANA registration numbers for different crypto algorithms in the coming face-to-face meeting.

Best regards.

Haiguang

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

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]<mailto:[email-masked]>>
抄送: Xialiang (Frank, Network Standard & Patent Dept) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
主题: Re: [netconf] I-D Action: draft-ietf-netconf-crypto-types-09.txt

Hi Martin,

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.

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

[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.

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.

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

[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

---

From: tom petch <[email-masked]>
Date: Wed, 3 Jul 2019 10:59:27 +0000

----- Original Message -----
From: "Wang Haiguang" <[email-masked]>
Sent: Wednesday, July 03, 2019 11:17 AM

> Hi， all.
>
> I have some comments regarding the management of crypto algorithms
used by different protocols such as TLS, IPSec and SSL.
>
> At the moment, different work group maintains own definitions
regarding the crypto algorithms, including public key algorithms, key
exchange algorithms, hash, mac, encryptions etc.
> Each working group defined their own identifiers for crypto
algorithms. In some group, crypto algorithms for authentication,
encryption and key exchange etc. are defined separately while others may
combined identifiers.
> The current method requires additional efforts in each group for
protocol development, and also in implementation and network management.
>
> A better way could be that the IETF security group define a unified
crypto algorithm identifiers and register them with IANA. These crypto
algorithm identifiers can be shared among  different working groups in
their future work.
> I think we should discuss this point and make a decision whether we
should get IANA registration numbers for different crypto algorithms in
the coming face-to-face meeting.

Yes:-) trouble is, WGs are independent and even if they are in the same
area with the same AD, it can be a challenge to get a common approach.
(I have been trying, mostly failing, to get a coordinated approach in
Routing where an interface can have different attributes0.

Here, there is also a technical challenge that the potential list of
algorithms is long, different protocols have different views of what is
current, what is obsolete and so on so we could and should create a list
of everything we can think of and get a Security directorate view of
which are acceptable, in terms of strength, for what; and, perhaps, add
a tick list of which protocols use them, so that it is easy to extract
all those with e.g. IPsec in the ticklist, for use by IPsec, which would
be different list for those with NETCONF in the tick list.

Then all we can do is make it easy to use, widely known about and
encourage others to use - or tell us why not.

But the first step, which, after much discussion, we have yet to take,
is to create a list. I prefer multiple lists, for encrypt, MAC and so
on, easier to maintain.

Tom Petch

> 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.
> 抄送: Xialiang (Frank, Network Standard & Patent Dept)
<[email-masked]<mailto:[email-masked]>>;
[email-masked]<mailto:[email-masked]>
> 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.
> [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?
> Kent // contributor

------------------------------------------------------------------------
--------

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

---

From: "Xialiang (Frank, Network Standard & Patent Dept)" <[email-masked]>
Date: Thu, 4 Jul 2019 09:55:44 +0000

Hi Tom,
Agree with your general observation.

Please see inline:

-----邮件原件-----
发件人: tom petch [mailto:[email-masked]] 
发送时间: 2019年7月3日 18:59
收件人: Wang Haiguang <[email-masked]>; Xialiang (Frank, Network Standard & Patent Dept) <[email-masked]>; Kent Watsen <[email-masked]>; Martin Bjorklund <[email-masked]>
抄送: [email-masked]
主题: Re: [netconf] : I-D Action: draft-ietf-netconf-crypto-types-09.txt

----- Original Message -----
From: "Wang Haiguang" <[email-masked]>
Sent: Wednesday, July 03, 2019 11:17 AM

> At the moment, different work group maintains own definitions
regarding the crypto algorithms, including public key algorithms, key exchange algorithms, hash, mac, encryptions etc.
> Each working group defined their own identifiers for crypto
algorithms. In some group, crypto algorithms for authentication, encryption and key exchange etc. are defined separately while others may combined identifiers.
> A better way could be that the IETF security group define a unified
crypto algorithm identifiers and register them with IANA. These crypto algorithm identifiers can be shared among  different working groups in their future work.
> I think we should discuss this point and make a decision whether we
should get IANA registration numbers for different crypto algorithms in the coming face-to-face meeting.

Yes:-) trouble is, WGs are independent and even if they are in the same area with the same AD, it can be a challenge to get a common approach.
(I have been trying, mostly failing, to get a coordinated approach in Routing where an interface can have different attributes0.

Here, there is also a technical challenge that the potential list of algorithms is long, different protocols have different views of what is current, what is obsolete and so on so we could and should create a list of everything we can think of and get a Security directorate view of which are acceptable, in terms of strength, for what; and, perhaps, add a tick list of which protocols use them, so that it is easy to extract all those with e.g. IPsec in the ticklist, for use by IPsec, which would be different list for those with NETCONF in the tick list.

[Frank]: Agree that ticklist is an each way for this goal, a minor problem is the basic list will be the maximum list for all the protocol and will be very large. The other similar idea in my mind is: firstly, we should have one basic crypto algorithm IANA list, which is a basis for each specific protocol's algorithm list. Secondly, each protocol (i.e., tls, ipsec, ssh ...) inherits the basic algorithm list with required modification (i.e., add new algo, obsolete old algo, ...). Lastly, any update of the basic list must reflect into each protocol's list, but each protocol's list can have its own update with no influence back to basic list. By this way, the basic list can be a minimum list, and each protocol's list only needs to focus on the left part in addition to basic list.

Then all we can do is make it easy to use, widely known about and encourage others to use - or tell us why not.

But the first step, which, after much discussion, we have yet to take, is to create a list. I prefer multiple lists, for encrypt, MAC and so on, easier to maintain.

[Frank]: agree too with this way forwarding. We have nearly finished the crypto algorithms list definition in draft-ietf-netconf-crypto-types-10. So, my question is can we publish it as the RFC before the IANA list is created?

B.R.
Frank

Tom Petch

> 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.
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;
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.
> 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.
> [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?

---

From: Wang Haiguang <[email-masked]>
Date: Fri, 5 Jul 2019 02:04:13 +0000

Hi， Tom

Thanks very much for the suggestion. 

Frank give a good suggestion, a better way could be we publish the RFC first and then create the IANA list later. 

Regards.

Haiguang

-----Original Message-----
From: Xialiang (Frank, Network Standard & Patent Dept) 
Sent: Thursday, July 4, 2019 5:56 PM
To: tom petch <[email-masked]>; Wang Haiguang <[email-masked]>; Kent Watsen <[email-masked]>; Martin Bjorklund <[email-masked]>
Cc: [email-masked]
Subject: 答复: [netconf] : I-D Action: draft-ietf-netconf-crypto-types-09.txt

Hi Tom,

Please see inline:

-----邮件原件-----
发件人: tom petch [mailto:[email-masked]]
发送时间: 2019年7月3日 18:59
收件人: Wang Haiguang <[email-masked]>; Xialiang (Frank, Network Standard & Patent Dept) <[email-masked]>; Kent Watsen <[email-masked]>; Martin Bjorklund <[email-masked]>
抄送: [email-masked]
主题: Re: [netconf] : I-D Action: draft-ietf-netconf-crypto-types-09.txt

----- Original Message -----
From: "Wang Haiguang" <[email-masked]>
Sent: Wednesday, July 03, 2019 11:17 AM

B.R.
Frank

Tom Petch

---

From: Kent Watsen <[email-masked]>
Date: Tue, 9 Jul 2019 22:00:05 +0000

This message proposes an approach for how to support algorithms that is quite different than in the current draft.

But, first, let me preface this by saying I continue to believe the current approach is ideal (as in idealistic), but fear that it may be trying to solve a problem that should be solved by the crypto community, not us (and hence not very practical).    To be ensure this is the case, the Chairs need to reach out to the Security Directorate for guidance.  With luck, a representative will be up to speed and able to attend our session Monday morning.  Stay tuned.

That being the case, I'd like to suggest an alternative approach, which is for ietf-crypto-types to define even more ASN.1 types, specifically, ASN.1 types for public and private keys.   But, first, let me explain how I came to think of this idea.  As mentioned before, I'm implementing ietf-restconf-server and when I got to the point of needing to populate values for the public and private key nodes, I took a shortcut of just storing the DER-encoded ASN.1 values provided by a utility such as OpenSSL.  Of course, ietf-restconf-server is primarily about HTTP over TLS, and hence it's common a create keys in the process of generating the PKI hierarchies needed to support TLS trust-anchor and end-entity certificates.   I was just being lazy at the time but, after awhile stewing on it, I'm wondering if this might not be an idea worth standardizing.

To be clear, the idea is to define the public/private key nodes as being ASN.1 types and, in doing so, inherit the algorithm identities used by ASN.1, thus negating the need to define any YANG-level identities.

Framing this idea a little more, if we were to do this:

1) ietf-crypto-types might be better titled ietf-asn1-types.  Already the module defines many ASN.1 types (listed below) and, after adding a few more ASN.1 types for the public and private key structures, and removing the identities/enumerations for the algorithms, all the typedefs would there be ASN.1 based.   [Here are the current ASN.1 types defined in the current module: x509, crl, cms, data-content-cms, signed-data-cms, enveloped-data-cms, digested-data-cms, encrypted-data-cms, authenticated-data-cms, trust-anchor-cert-x509, end-entity-cert-x509, trust-anchor-cert-cms, and end-entity-cert-cms.]

2) the solution in the suite of client-server drafts would be very much ASN.1 oriented.  This would be (for the most part) splendid for TLS-based protocols, but not very helpful for other protocols, notably SSH (unless using the X.509 extensions per RFC 6187).   It sounds limiting but, let's be honest, TLS is the basis for most protocols and hence this would be a 90% solution.  Further, when thinking about ietf-truststore, it's fairly uncommon to use trust-anchors with SSH.  And, for ietf-keystore, I'm unsure at this point to what extent keystores are used to protect SSH private keys - I've never seen a TPM/HSM used to protect an SSH key, unless the key were encrypted (as in the latest keystore draft), or was an X.509 end-entity certificate (per RFC 6187, albeit I don't know any vendor that supports RFC 6187 today).

3) this approach would do little to help the other WGs (e.g., SACM) with their YANG modeling endeavors.  Note that the reason my co-authors from Huawei were attracted to helping us with this effort was because they want to embrace-and-extend it for other work.  I'm not up-to-speed on that, and thus look to them to share more about the landscape in which this module fits.

Kent // contributor