Re: [Cfrg] TLS PRF security proof?

[Hugo Krawczyk <[e-mail]>]

​Let me provide some clarifications regarding this discussion.

If I understand correctly, Dan Brown's original posting referred to the TLS
PRF and its use of a feedback mode. Later postings started discussing HKDF
which uses this feedback mode but only as a component of a more general
functionality, namely, key derivation.

The crucial difference between KDFs and PRFs is that the latter are used to
expand a strong cryptographic key into several keys while KDFs assume that
you start with keying material of "sufficient entropy" but not contained in
the form of a short uniform (or pseudo-random) key. Thus, HKDF works in two
stages: a first stage that "extracts" a strong cryptographic key from the
input entropy and a second stage where this key is expanded into more
(cryptographically strong) keys using a PRF.

HKDF is defined in RFC 5869 which contains limited design and use rationale
but which is backed by a detailed article explaining such rationale:
http://eprint.iacr.org/2010/264.

The intention of the paper was to be written so that it contains the formal
treatment a mathematical cryptographer expects but also have intuitive
English discussions for the less formalist reader (actually, most of the
math background for the paper belongs to prior work). So I would encourage
people interested in the discussion in this thread to take a look at the
paper; it should answer some of the questions raised here such as the role
of salt, source independence, etc.).

In particular, the paper contains a short section on the rationale of using
feedback mode for the PRF part and its advantage over counter mode
(answering one of the points raised by Dan Brown). Indeed, I argue that
while counter mode is more natural it is also more vulnerable to future
weaknesses (*). It is also worth noting that HKDF adds an increasing
counter to the feedback iterations that is not part of the TLS definition
and was added to defend against (theoretical) hash cycles. I would
recommend that any revision of TLS that changes its key derivation adopts
HKDF as defined in RFC 5869.

A general comment to address some of the more specific issues raised in
this discussion: The basic design goal of HKDF is to serve as a
multi-purpose design. One that works in all key derivation scenarios (from
whitening the output of a physical RNG to extracting randomness from pools
of entropy to deriving keys in key exchange protocol) and with different
assumptions on the underlying cryptographic hash functions. In particular,
confining the use of idealized assumptions (e.g., random oracle) or even
collision resistance to the minimum necessary. The important point is that
you get the benefits of the design without having to customize it on a
per-use basis.

Hugo

(*) This PRF mode of operation (introduced in the early design of IKEv1,
from which it found its way to TLS via SSLv3) was "inspired" by the early
weaknesses of MD5 (Dobbertin work). I thought at the time that we better
design safegueards to protect against future weaknesses of our beloved
functions. I believe we should stick to that principle.