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

[Yaron Sheffer <yaronf.ietf@xxxxxxxxx>]

Hi Russ,

 

Please see my answers in-line.

 

Thanks,

                Yaron

 

From: Russ Housley <housley@xxxxxxxxxxxx>
Date: Friday, November 26, 2021 at 17:53
To: Yaron Sheffer <yaronf.ietf@xxxxxxxxx>
Cc: Kent Watsen <kent+ietf@xxxxxxxxxx>, IETF SecDir <secdir@xxxxxxxx>, draft-ietf-netconf-sztp-csr.all@xxxxxxxx <draft-ietf-netconf-sztp-csr.all@xxxxxxxx>, last-call@xxxxxxxx <last-call@xxxxxxxx>, netconf@xxxxxxxx <netconf@xxxxxxxx>
Subject: Re: Secdir last call review of draft-ietf-netconf-sztp-csr-11

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 think we should explicitly mention what this method *cannot* provide. As far as I can tell, none of the origin authentication methods are available when using PKCS #10 directly without wrapping it further.

·          

·         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.

 

Yes, but the Heninger et al. reference is a better fit than the Debian CVE because (1) it discusses network devices rather than servers and (2) it shows how even less broken RNGs can be exploited by a network attacker that only sees the public keys.

 

 

·         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.

 

Not really, because the “protocol” described here is: Client sends a CSR, Server responds with a complete client configuration blob. This obviously doesn’t work for an already deployed client.

·          

·         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.

 

Agreed. Sigh.

 

Russ

 

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