Re: [Cfrg] TLS PRF security proof?

[Andy Lutomirski <[e-mail]>]

On Wed, Jul 9, 2014 at 8:33 AM, Andy Lutomirski <[e-mail]> wrote:
> On Wed, Jul 9, 2014 at 8:28 AM, Paul Hoffman <[e-mail]> wrote:
>>
>>> 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).
>

I should note that this text in 3.4 smells funny to me even taken
alone.  Making sure that the nonces come from legitimate parties does
*not* imply that they are independent of the IKM in any sense of the
word "independent" that I understand.

I, and presumably protocol designers everywhere, would much prefer
language that tells me "this primitive provides this security
guarantee if this condition is met" where the condition is clearly
specified.

This is not to say that HKDF is not a perfectly good KDF, but I find
the RFC 5869 language unconvincing.

--Andy