Re: [Crypto-panel] Request for review: draft-irtf-cfrg-randomness-improvements

[Russ Housley <[e-mail]>]

Document: draft-irtf-cfrg-randomness-improvements-10
Reviewer: Russ Housley
Review Date: 2020-03-15


The CFRG Chairs asked the Crypto Panel to review this document.
I am providing one review.  There may be others.


Summary:

A technique for improving the security of a random number generator
is provided.  Nice work, but some improvements in the document are
desirable before publication as an Informational RFC.


Major Concerns:

Section 3 requires that "Sig MUST be a deterministic signature
function".  This is inconsistent with the third paragraph in
Section 9.  I think that any "good" signature algorithm with a
"properly" generate private key should work out fine.  So, please
remove the requirement for a deterministic signature function.

Section 4 says: "See Section 5 for example protocol information that
can be used in the context of TLS 1.3."  I did not find that in
Section 5 or anywhere else.

Section 9: Please inclue the rationale for this requirement that
L >= n - L' for each value of tag2.


Minor Concerns:

Abstract: I think it is too long.  I think the examples of broken
random sources can be moved to the Introduction.

Abstract and Intoduction: Why call out TLS?  TLS, IPsec, S/MIME, PGP,
and every other security protocol relies upon random numbers.

Section 4: A real-time clock should be listed as a possible source for
a portion of the tag2 value.


Nits:

I do not think the assignment of "Adv" to the adversary helps explain
the goals.  I think plain English is fine here.  I suggest:

Section 1: s/An adversary Adv with /An adversary with /

Section 1: s/by adversary Adv,/by an adversary,/

Section 1: s/unknown to Adv./unknown to the adversary./


Suggestion:

Appendix A of [SecAnalysis] required an implementation of the algorithm,
with reasonable choices for all of the parameters.  I think it would be
useful to put that pseudo-code in an Appendix of this document along
with a test vector.