[Cfrg] Spencer Dawkins' No Objection on draft-irtf-cfrg-randomness-improvements-12: (with COMMENT)

[Spencer Dawkins via Datatracker <[e-mail]>]

Spencer Dawkins has entered the following ballot position for
draft-irtf-cfrg-randomness-improvements-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-irtf-cfrg-randomness-improvements/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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.