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

["Xialiang (Frank, Network Standard & Patent Dept)" <[e-mail]>]

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:[e-mail]]
发送时间: 2019年6月27日 8:06
收件人: Martin Bjorklund <[e-mail]>
抄送: Xialiang (Frank, Network Standard & Patent Dept) <[e-mail]>; [e-mail]
主题: 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