Re: [netconf] crypto-types fallback strategy

["Salz, Rich" <[e-mail]>]

Yes there is churn.  We prefer to call it “change” or “evolution” :)  We hope that our protocols and data structures have enough flexibility, known as crypto agility, so that we don’t have to do huge revisions (as was the case when the MD5 digest was broken, for example).

Predicting the future is hard, especially for crypto, and this WG shouldn’t try.  That means that if the WG wants to keep current with best crypto practices, it probably should have smaller easy-to-revise documents rather than a single encyclopedia. (Apologies for repeating myself.) I don’t know the best way for this WG to do that as I am a netconf newbie.

As for the TLS ciphersuite evolution Tom mentioned, I can comment.  I am one of the TLS registry “expert reviewers.”  Yes, TLS 1.2 has dozens of algorithms supported; TLS 1.3 has eight.  While others may be added, they will be “not commended” (a new column added). My question is, do the ciphersuites matter in TLS configuration?  For most configurations that I see (including Akamai customers in my day job), it’s a random text string. Why does TLS configuration need more than a cert or two (RSA and ECDSA), the corresponding private keys, and a text list of ciphersuites?

Similarly, in my experiences with SSH, it’s about public keys (for hosts you talk to) and private keys.

I don’t think this WG needs to think about symmetric/bulk encryption keys at this point. Of course, I could be wrong and would love to understand why, if so.