Randomness Improvements for Security Protocols
draft-irtf-cfrg-randomness-improvements-14

The document is generally clear in its objective and methods. One comment is on "the length  M" at the 2nd paragraph in section 3 "Randomness Wrapper". It is not explicitly described how to decide this value. 

In RFC 5869, it is stated as below：
"Ideally, the salt value is a random (or pseudorandom) string of the length HashLen.  Yet, even a salt value of less quality (shorter in size or with limited entropy) may still make a significant contribution to the security of the output keying material" 

But to the specific application in this draft, it is not sure M chould be almost arbitary, or M =< L, or there are more specific suggestions from best practices.

Not being an expert in the field, I read the document from a high-level point of view. 
The document is sufficiently well-written to be understandable from a wide audience, and is clear in its goal.
Only a minor suggestion: when using "an adversary Adv", it may be better to put 'Adv' to avoid any confusion with another meaning or misspelling of a word or acronym.

My comments were addressed properly.

One minor editorial comments: I'm not sure I full understand the term "participants" in the abstract. Maybe there is better word?

And further I would recommend to split reference up in normative and informational, given it's clear that not all listed reference are normative to understand this document.

This seems a fine document. I do have some nits, and questions about BCP14 usage. Do the right thing, of course. 

I'm thinking that the mentions of "Dual_EC_DRBG" and "Debian bugs" may not be meaningful to future readers ("RFCs are forever") in the Abstract without references (which we don't put in Abstracts). 

   Randomness is a crucial ingredient for Transport Layer Security (TLS)
   and related security protocols.  Weak or predictable
   "cryptographically-strong" pseudorandom number generators (CSPRNGs)
   can be abused or exploited for malicious purposes.  The Dual_EC_DRBG
                                                       ^^^^^^^^^^^^^^^^
   random number backdoor and Debian bugs are relevant examples of this
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   problem.  An initial entropy source that seeds a CSPRNG might be weak
   ^^^^^^^
   or broken as well, which can also lead to critical and systemic
   security problems.  This document describes a way for security
   protocol participants to augment their CSPRNGs using long-term
   private keys.  This improves randomness from broken or otherwise
   subverted CSPRNGs.
   
Perhaps that sentence could be omitted, since both are mentioned in the Introduction with references?

I know that CSPRNG is expanded in the Abstract, but I'd suggest expaanding it on first use in the text. 

   Randomness is a crucial ingredient for TLS and related transport
   security protocols.  TLS in particular uses random number generators
   (generally speaking, CSPRNGs) to generate several values: session
                        ^^^^^^^
						
I understood 

   2.  An adversary Adv with full control of a (potentially broken)
       CSPRNG and able to observe all outputs of the proposed
       construction, does not obtain any non-negligible advantage in
       leaking the private key, modulo side channel attacks.
	                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^
								
as saying "without using side channel attacks" - did I get that right? But you might consider being a little less terse than "modulo". 

This text
   Let G(n) be an algorithm that generates n random bytes, i.e., the
   output of a CSPRNG.  Define an augmented CSPRNG G' as follows.  Let
   Sig(sk, m) be a function that computes a signature of message m given
   private key sk.  Let H be a cryptographic hash function that produces
   output of length M.  Let Extract(salt, IKM) be a randomness
   extraction function, e.g., HKDF-Extract [RFC5869], which accepts a
   salt and input keying material (IKM) parameter and produces a
   pseudorandom key of L bytes suitable for cryptographic use.  It must
   be a secure PRF (for salt as a key) and preserve uniformness of IKM
   (for details see [SecAnalysis]).  L SHOULD be a fixed length.  Let
   Expand(k, info, n) be a variable-length output PRF, e.g., HKDF-Expand
   [RFC5869], that takes as input a pseudorandom key k of L bytes, info
   string, and output length n, and produces output of n bytes.
   Finally, let tag1 be a fixed, context-dependent string, and let tag2
   be a dynamically changing string (e.g., a counter) of L' bytes.  We
   require that L >= n - L' for each value of tag2.
   
has an interesting mix of normative ("SHOULD"), apparently non-normative ("MUST"), semi-normative ("We require that X"), and asserted ("Let A be X") constraints. Are you sure this variety is necessary? At a minimum, you might consider giving guidance about when an implementer might use variable-length Ls, so that implementers could better understand when it's appropriate to use them. 

Is
   Both tags SHOULD be generated such that they never collide with
   another contender or owner of the private key.  This can happen if,
   for example, one HSM with a private key is used from several servers,
   or if virtual machines are cloned.
   
actually a normative SHOULD? If the tags do collide, what happens? (If it's Really Bad, why is this not a MUST?) Is there a reason an implementer would need to ignore this requirement?

I have roughly the same question about 

  Tag strings SHOULD be constructed as follows:
              ^^^^^^
  
What happens if they aren't? Why would an implementer need to construct them some other way?

And about 

   Recall that the wrapper defined in Section 3 requires L >= n - L',
   where L is the Extract output length and n is the desired amount of
   randomness.  Some applications may require n to exceed this bound.
   Wrapper implementations SHOULD support this use case by invoking G'
                           ^^^^^^
   multiple times and concatenating the results.
   
Wha happens if the implementation doesn't? Why would an implementation need to support this use case some other way?

In this text

   The proposed construction cannot provide any guarantees of security
   if the CSPRNG state is cloned due to the virtual machine snapshots or
   process forking (see [MAFS2017]).  Thus tag1 SHOULD incorporate all
                                                ^^^^^^
   available information about the environment, such as process
   attributes, virtual machine user information, etc.
   
the second sentence looks more like guidance than a normative requirement to me.