Re: [netconf] crypto-types fallback strategy

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Kent,

From: Kent Watsen <[e-mail]>
Sent: 16 September 2019 17:49
To: Rob Wilton (rwilton) <[e-mail]>
Cc: [e-mail]; Russ Housley <[e-mail]>; Rifaat Shekh-Yusef <[e-mail]>; Sean Turner <[e-mail]>
Subject: Re: [netconf] crypto-types fallback strategy


Hi Rob,




1.      I think that using a numerical OID to identify crypto algorithms doesn’t seem like a great choice.  Seeing a config file say something like “rsaEncryption” instead of some OID string seems to be much more human friendly.  And as Martin says, using the OID name has no guarantees of being unique.

On only this very last point, I'm unsure about that.
[RW]
The full numerical OID string is unique, but very hard to be interpreted by a human.  The human readable OID name (e.g. for just the last element) is not unique.

I agree with Juergen, in that I think that using OIDs as names for encryption protocols is probably a mistake and tying us into the past.





2.      I wonder if changing from identifiers to enums was a mistake.  If we were to use YANG identifiers then we wouldn’t need to define them all now, and they wouldn’t all need to be defined in the same YANG module.  In fact, if we were to go back to using identifiers then perhaps NETCONF should restrict itself to only defining the identifiers that we actually need now, and leave the rest to the security folks to figure out, probably as separate modules defining the extra identifiers that they need, or as a bis version of the crypto-types draft if required.

Seems like a reasonable approach, but I don't know how that differs, in the end, from the uber definition some folks have voiced a concern for.  Maybe we need to understand better what that concern is better.
[RW]
Oops, my comment about should have been identities rather than identifiers!

I think that it is helpful that identities are extensible and can easily be constructed in a modular way.  E.g. defining identities in different YANG modules, and/or putting them under if-feature allows implementations to choose which ones they actually support.

In ietf-crypto-types I would define the base identities for:


hash-algorithm, asymmetric-key-algorithm, mac-algorithm, encryption-algorithm, encryption-and-mac-algorithm, signature-algorithm, key-exchange-algorithm

Note, as an aside, I am I also wondering whether the “encryption-and-mac-algorithm” identity should derive from both “mac-algorithm” and “encryption-algorithm”?  Or perhaps it doesn’t need to be defined at all, and the actual identities can just derive from two base identities?

I then suggest that we put different identities into different YANG modules, perhaps something roughly like:

  *   Ietf-crypto-sha-types.yang for the SHA hash identities (RFC 6234)
  *   Ietf-crypto-rsa-types for RSA asymmetric-key-algorithm (RC 8017)
  *   Ietf-crypto-elliptic-curve-types for the Elliptic Curve based algorithms (RFC 6090, 5480, 8422)
  *   Ietf-crypto-mac-types – I’m not really sure how to organize the MAC algorithm types, or even if they need to be defined now.
  *   Ietf-crypto-aes-types – AES encryption types (RFC 4309)
  *   Ietf-crypto-ssh-types – das-sha1, rsaasa-pkcs1-sha1 (RFC 4253)
  *   Ietf-crypto-tls-types – (RFC 8446)
  *   Ietf-cyprto-dhe-types – Diffier Hellman key exchange (RFC 7919).  Actually, the key-exchanges algorithm types might need to be split up a bit further.

The key step is that I would say that NETCONF should only standardizes the ones that we need now.  For the others, we could potentially create the YANG modules and either hand this off to the security groups, or work whether them to standardize these through the appropriate WGs.




3.      I’m not sure that I understand why we would always want to always use ASN.1 to describe the keys for all algorithms.  Could we just leave the algorithm identities to define what format they use?   If we were to go back to using identities when we could have the choice of using multiple inheritance and then have a separate set of identities to allow the key formats to be defined.  Note, I have no objection to ASN.1 being used for some/most the keys if that is the right encoding.

Perhaps we can do both, say that the field is parsed according to its "algorithm" value, but for now, all algorithm identifiers happen to point to ASN.1 structures.
[RW]
Yes, in essence I think that is what I’m suggesting.

If this is really common, then an identity for “ASN.1 encoded” could also be defined and inherited by crypto type identities above.  I think that this depends on how useful it is to programmatically know that they are encoded in ASN.1

Thanks,
Rob

Hopefully the comments are useful, apologies if they are not!

All good.  Keep them coming.


Kent