Re: [Last-Call] Secdir last call review of draft-ietf-netconf-sztp-csr-11

[Russ Housley <housley@xxxxxxxxxxxx>]

Yaron:

Thank you for addressing my comments, I am happy with most of your responses but I do have a few remaining questions:

 

• The commit that removes the dependency on IDevID and LDevID does not fix the issue of non-orthogonality. There is very detailed description for CMP and CMC, but nothing for PKCS #10 (p10-csr). Does it mean “use PKCS#10 out of the box and it’ll just work”? Or does it mean “the usage of PKCS#10 for these certs is still TBD”?

PKCS#10 is pretty simple.  Are you aware of anything more that ought to be said?

• I suggest to add the following reference to the paragraph on quality randomness, as a strong proof that this is a real world concern:

 

Heninger, N., Durumeric, Z., Wustrow, E., and J. Halderman, "Mining Your Ps and Qs: Detection of Widespread Weak Keys in Network Devices", Proceedings of the 21^st USENIX Security Symposium , August 2012, <https://factorable.net/>.

In another thread, something like this was suggested for another document:

   Implementations must randomly generate nonces and private keys.

   The use of inadequate pseudo-random number generators (PRNGs) to

   generate cryptographic keys can result in little or no security. An attacker

   may find it much easier to reproduce the PRNG environment that

   produced the keys, searching the resulting small set of possibilities,

   rather than brute force searching the whole key space. As example for

   predictable random numbers see CVE-2008-0166 […]. The generation

   of quality random numbers is difficult. ISO/IEC 20543:2019 […],

   NIST SP 800-90A Rev.1 […], BSI AIS 31 V2.0 […], BCP 106 [RFC4086], and

   others offers valuable guidance in this area.

If this approach works for you, we'll dig up the appropriate references.

 

• I understand that key generation is out of scope and maybe this needs to be a separate work item, but recommending periodic replacement of the certs without recommending a suitable mechanism leaves this solution with a big hole.

I do not agree.  It does offer the protocol for obtaining replacement certificates for devices that are able to generating a fresh public/private key pair.  Getting more detailed would be algorithm specific, which is not appropriate in this document.

• It is really annoying that 21 years after PKCS #10, we still cannot provide a reference that would enable implementers to find out all available, non-deprecated AlgorithmIdentifier values. (And I realize there’s little you can do about it.)

So, we will leave this part alone.

Russ

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call