Re: [Cfrg] TLS PRF security proof?

[Andy Lutomirski <[e-mail]>]

On Wed, Jul 9, 2014 at 5:58 AM, Dan Brown <[e-mail]> wrote:
> ‎TLS has been asking for CFRG input on curves, so maybe TLS is now more open to a suggestion like HKDF for future updates.
>
> Furthermore, the latest TLS 1.3 draft makes a point of lacking a security analysis: thus my question to this list. (Not to the TLS list, because of the research nature of the question. )
>
> I'll ask the converse question: besides provable security, what advantage would HKDF have over TLS PRF? Eg, does HKDF fare better than TLS PRF under some disastrous HMAC failure? In other words, if proofs cover the sufficient conditions, what about the necessary conditions? Does the HKDF RFC answer all this already?

I can't speak for the TLS WG, but from my own perspective, I have
three problems with HDKF:

1. HKDF is parametrized by a hash.  What hash should people use?
(Hence my suggestion of using combiners -- changing the PRF in an
existing protocol is a real PITA and might not even be possible
without introducing security holes.)

2. The RFC didn't make the security properties clear to me.  For
example, protocols should stick nonces into the salt.  Oh, wait, they
shouldn't stick nonces into the salt without care.  Can I use multiple
"info" values to safely extract key material and publish it?

3. (Only relevant to hashes using MD construction) My understanding of
HMAC is that it's secure against generic attacks on MD hashes if the
key is secret and unpredictable.  HKDF doesn't necessarily use a
secret, unpredictable key for HMAC.  Is HKDF-SHA-1 insecure as a
result?  What about HKDF-SHA-512 against an adversary with unlimited
precomputation power?


--Andy