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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 21st 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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux