Re: [TLS] PRF in 1.3

[Michael StJohns <[e-mail]>]

On 8/6/2014 7:43 AM, Henrik Grubbström wrote:
>> that - see
>> >http://tools.ietf.org/html/draft-stjohns-tls-tls13-crypto-infra-00, and I
>> >would add information about the types and lengths of the keys to be derived
>> >from the key stream to the context.  With those changes, a recursive based
>> >HMAC PRDG at the heart of the KDF is probably sufficiently secure for key
>> >derivation going forward.
> I'd like to hear from the people that rejected P_SHA256 for the AES256
> suites in RFC 5289 (which instead use P_SHA384). I suspect that it is
> to avoid leaking the entire state of the PRF in the AES256 keys and/or
> to avoid correlation between the client-side and server-side keys.

I think this is actually not a question with respect to the KDF use of 
the PRF, but with the "PRF(k, HASH(handshake messages))" formation of 
the verify_data in the Finished messages.

HMAC_SHAXXX (k, data) is XXX bits of strength secure, but SIGN (k, 
SHAXXX(data)) (which is really what the PRF is being used for here) is 
only XXX/2 bits of strength - or so I understand from the NIST key 
management special publication.    That would place the strength of a 
suite with a PRF P_SHA256 at not greater than 128 bits for TLS1.2 and 
before.

Mike