Re: [Cfrg] soliciting feedback on HKDF

[Simon Josefsson <simon at josefsson.org>]

I believe this is a useful document, nice work!

There is one part which appears (intentionally) underspecified that I
fear may lead to a sub-optimal deployment scenario.  The document says:

4. Applications of HKDF
...
   One significant example is the derivation of cryptographic
   keys from a source of low entropy such as a user's password.
   ...
   Therefore, PBKDF
   applications interested in adapting HKDF to their setting can either
   replace the extract step with an intentional slow-down mechanism
   (e.g., applying repeated hashing) or can use both the extract and
   expand mechanism of HKDF with a slowing-down mechanism applied after
   the extract step and before expansion.

If implementers take this suggestion literally, there is a risk that we
will end up with more than one HKDF-derived password-based KDF with
slightly different properties.

We already have one standardized PBKDF: PKCS#5 PBKDF2 from RFC 2898.  It
is close in spirit to the HKDF.

Q: Does the PBKDF2 have some sub-optimal property that suggests we need
to consider replacements?

If there is not (I am not aware of any reason), I suggest the HKDF
document should recommend applications that are interested in a PBKDF to
look at RFC 2898 PBKDF2 rather than suggesting to invent something based
on HKDF.

The alternative would be to specify a "standard" password-based HKDF
function in the the HKDF document that also takes an iteration count to
burn some cycles.

Given that PKCS#5 PBKDF is already deployed in several protocols, I
believe we need a good rationale for introducing another PBKDF at this
point.

FWIW, understanding if there is any problem with the PBKDF2 would be
useful in the context of the upcoming SCRAM-SHA-1 SASL mechanism too.

Thanks,
/Simon