Re: [Cfrg] comments and questions on draft-krawczyk-hkdf and related work

[<Pasi.Eronen at nokia.com>]

Hi David,

I'll try to answer the parts of spec-writing (since I'm definitely
not a cryptographer):

<snip>
> The draft is somewhat incomplete as a normative specification, in that
> it does not require the implementation of any particular hash (would
> it make sense to include the recommended instantiation from the
> paper?).  Also, it does not use any of the RFC 2119 keywords.  I would
> expect that, to be used in standards, it would be necessary to at
> least provide some recommended instantiations and the security levels
> that they target.

I don't think we need a mandatory instantiation in this document (it
would be defined in the protocol using this KDF -- the HMAC spec, RFC
2104, has the same approach).. so it's some sense intentionally
incomplete, as it can't be used alone, but always as part of some
protocol.

But perhaps some discussion about the security level (perhaps a
pointer to NIST's document about these, or copying the table from
there) would be good.

<snip>
> I wonder if we really want to target all of these disparate cases with
> a single KDF function.  Applications using just case #1 may reject
> adopting HKDF on the reasonable grounds that they don't need the
> extraction stage, and that adopting HKDF with the suggestion of
> Section 3.3 to skip that stage would amount to replacing a perfectly
> OK PRF with another PRF that offers no security advantage.

The document doesn't propose replacing PRFs in existing protocols with
HKDF -- that would be mostly unproductive work (and thus bad
engineering). It's more intended for new protocols (or perhaps to
situations where folks have already agreed that the existing PRF in
some protocol is definitely not OK -- but I don't have any 
such situation in mind currently).

> IKE and TLS both use a PRF for applications #1 and #2, but are there
> other protocols that use a single PRF in multiple applications?  There
> is a listing of some IETF references to KDFs at
> http://www.mindspring.com/~dmcgrew/ic/internet-crypto.html#prfs and,
> besides IKE, these uses seem to belong to just a single case.  There
> are also some other protocols with built-in single-purpose KDFs that
> are not externally documented, such as SRTP's AES-CTR based KDF
> and EAP TLS key derivation.
> 
> If IKE and TLS are the main intended applications, I suggest adding a
> discussion of these applications to the draft.  It would be valuable
> to compare HKDF to the existing KDF functions used in those protocols.

As noted above, this is mostly meant as a building block for writers
of new protocol specifications, not as change to existing protocols.
So TLS is definitely not an intended applications of this (it's already
used in IKE).

Best regards,
Pasi