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

["Stanislav V. Smyshlyaev" <[e-mail]>]

Dear Martin and Rich,

Many thanks for your positive feedback, for your comments and
considerations!

Regarding the last question of Martin, we (Cas, Christopher, Luke, Nick,
Liliya and I) believe that the following additional statement in the I-D
after
"Let Extract(salt, IKM) be a randomness extraction function, which accepts
a salt and input keying material (IKM) parameter and produces a
pseudorandom key of length L suitable for cryptographic use."
will help:
«It must be a secure PRF (for salt as a key) and preserve uniformness of
IKM (for details see [SecAnalysis])».
It should be sufficient to avoid any confusion and point to the right place
as well. We'll add this statement after the I-D submission is open again.

Regarding the other minor concerns – we've addressed a few of them in the
updated version of the I-D, which we managed to submit yesterday before the
cut-off; after the submission is open again, we'll address all other ones.

Kindest regards,
Stanislav

чт, 4 июл. 2019 г. в 03:57, 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
> >
>
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg
>