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