Re: [Cfrg] TLS PRF security proof?

[Andy Lutomirski <[e-mail]>]

On Wed, Jul 9, 2014 at 8:28 AM, Paul Hoffman <[e-mail]> wrote:
> On Jul 9, 2014, at 8:18 AM, Andy Lutomirski <[e-mail]> wrote:
>
>> 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?
>
> Any one that has no known weakening of preimage resistance. That is: nearly any of them.
>
>> (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.)
>
> Adding more choices makes interoperability less likely. In real-world protocols, excellent interoperability with almost-perfect security is *much* better than good interoperability with perfect security.
>
>> 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 you justify that second sentence with anything from RFC 5869? In fact, it says the opposite:
>
>    Ideally, the salt value is a random (or pseudorandom) string of the
>    length HashLen.  Yet, even a salt value of less quality (shorter in
>    size or with limited entropy) may still make a significant
>    contribution to the security of the output keying material; designers
>    of applications are therefore encouraged to provide salt values to
>    HKDF if such values can be obtained by the application.

Quoting from RFC 5869, section 3.4:

   Independence is also an important aspect of the salt value provided
   to a KDF.  While there is no need to keep the salt secret, and the
   same salt value can be used with multiple IKM values, it is assumed
   that salt values are independent of the input keying material.  In
   particular, an application needs to make sure that salt values are
   not chosen or manipulated by an attacker.  As an example, consider
   the case (as in IKE) where the salt is derived from nonces supplied
   by the parties in a key exchange protocol.  Before the protocol can
   use such salt to derive keys, it needs to make sure that these nonces
   are authenticated as coming from the legitimate parties rather than
   selected by the attacker (in IKE, for example this authentication is
   an integral part of the authenticated Diffie-Hellman exchange).


>
>> Can I use multiple
>> "info" values to safely extract key material and publish it?
>
> Yes. Can you point at something in the RFC that indicates any different?

No, but it wasn't clear to me that this property was guaranteed.

>
>> 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?
>
> For the discussion at hand, the key is secret and unpredictable.

I believe this, but I'd like to imagine that we've reached the point
where we don't need weird hacks (i.e. HMAC) and overcomplicated
analysis to work around the generic weaknesses of old hashes.  Oh,
well -- this is more of an aesthetic issue than a security issue.

--Andy