Re: [Cfrg] RGLC on draft-irtf-cfrg-randomness-improvements-05

["Martin Thomson" <[e-mail]>]

This is good, though I have a number of editorial comments, and a question (the answer to which seems important, but I am happy to be wrong).

The use of "let x be" in the first paragraph of Section 2 isn't necessary.  You don't use 'x' anywhere but in that statement, so it could be rephrased more simply.

   When properly instantiated, the output of a CSPRNG should be indistinguishable from a random string of bits.  However, as previously discussed, this is not always true.  To mitigate this problem, we propose an approach for wrapping CSPRNG output with a construction that mixes secret data into a value that may be lacking randomness.

In Section 2, the rules about release of Sig(..) are repeated:

   Sig(sk, tag1) should only be computed once for the lifetime of the
   randomness wrapper, and MUST NOT be used or exposed beyond its role
   in this computation.  

I believe that this is a "need only" rather than a "should only".  There is no requirement that the signature not be recalculated or replaced over time, only that there is no need to do so.  Use of "should" implies recommendation.  This follows from text that repeats this later: "In systems where signature computations are expensive, Sig(sk, tag1) may be cached."  Maybe only say this once.

  To achieve this, tag1 may have the format that
   is not supported (or explicitly forbidden) by other applications
   using sk.

The "may have the format" statement implies permissiveness in a 2119 sense, but the intent is to communicate a strategy for achieving the hard requirement.  Perhaps this could be reworded to say "If sk could be used for other purposes, then selecting a value for tag1 that is different than the form allowed by those other uses ensures that the signature is not exposed."  Is this statement better moved to Section 3, with only a forward reference here?

   In that case the relative cost of using G'(n) instead
   of G(n) tends to be negligible with respect to cryptographic
   operations in protocols such as TLS.  

You might instead say that the relatively inexpensive computational cost of HKDF dominates when comparing G' to G.

In Section 3, the "it" in this sentence isn't clear: "It is needed to address the problem of CSPRNG state cloning (see [RY2010]). "

The construction of tag2 is confusing.  I would instead say: "A nonce. That is, a value that is unique for each use of the same combination of G(n), tag1, and sk values.  The tag2 value can be implemented using a counter, or a timer, provided that the timer is guaranteed to be different for each invocation of G'(n)."

In Section 4, the recommended construction for tag1 fails to take into account some of the advice from Sections 3 and 7.  Specifically, it does not encode include information about the host.  And it does not explicitly point out that the value is constructed in a way as to be illegal in TLS 1.3 (because TLS 1.3 signature inputs all start with a sequence of 0x20).

And, buried at the bottom, the question:

I'm sure that the analysis covers this, but what are the concrete requirements on the randomness extraction and expansion functions?  You use HKDF as an example, but you don't restrict this to HKDF.  That implies some properties, but as we learned from TLS analysis, there are properties that HKDF provides that we might rely on that are different than a generic KDF function.  For TLS, one property we rely on HKDF providing is collision resistance (which follows from its use of collision-resistant hash functions).  It would appear here that this relies on preimage resistance.  As the intro says H(x, sk) might be sufficient, but that implies that H() provides preimage resistance.  This is never stated, but it seems rather important.

On Wed, Jul 3, 2019, at 23:57, Alexey Melnikov wrote:
> Dear CFRG participants,
> 
> This message is starting 2 weeks RGLC on 
> draft-irtf-cfrg-randomness-improvements-05 ("Randomness Improvements 
> for Security Protocols"), that will end on July 17th 2019. If you've 
> read the document and think that it is ready (or not ready) for 
> publication as an RFC, please send a message in reply to this email or 
> directly to CFRG chairs (Kenny Paterson <[e-mail]> 
> and Alexey Melnikov <[e-mail]> in this case). If you 
> also have detailed comments, these woulbe be very helpful at this point.
> 
> Thank you,
> 
> Alexey, for CFRG chairs.
> 
> 
> 
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg
>