Re: [TLS] PRF in 1.3

[Michael StJohns <[e-mail]>]

On 8/6/2014 3:11 PM, Martin Rex wrote:
> Michael StJohns wrote:
> [ Charset UTF-8 unsupported, converting... ]
>> 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.
> The PRF output is not used for in a signature style fashion.
>
> The default signature algorithm (for combination with RSA) in
> TLSv1.2 is either (sha1,rsa) or (md5,rsa), and particularly the
> latter is ludicrously weak in comparison to the tlsv1.[01] (sha1+md5,rsa).
>
> The problem with the Finished message in TLSv1.2 is that it still
> truncates the PRF output to 12 bytes (96 bits).  The HMAC rfc explictly
> says that one should not truncate to less than half the output size
> of the underlying hash function, so TLSv1.2 **should** have used
> Finished messages of at least 128 bits (16 octets) for a SHA256-based PRF,
> and at least 192 bits (24 octets) for a SHA384-based PRF.
>
> This is one of the TLSv1.2 goofs that should be fixed in TLSv1.3, btw.

I think you're still missing the point - the PRF *is* used as a 
signature function over a hash.  If the PRF were used as an HMAC 
signature function over the raw handshake data, it would be as secure as 
the HMAC (which is 256 bits for SHA256) underlying the PRF, but since 
you're signing the hash of the handshake data, you've no more security 
than the collision resistance of the hash which is 128 bites for SHA256.

The security of HMAC_SHA256 (key, SHA256 (data)) or PRF_SHA256(key, 
SHA256(data))  or ECDSA_521 (key, SHA256(data)) is no more secure than 
128 bits because the security of SHA256(data) is no more secure than 128 
bits for a signature function.

See table 3 of 
http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_general.pdf

I may be confused about this, but I don't think I am.

I think you're probably also right about the truncation issue for the 
finished message - but that's at least a little unclear because of the 
recursive nature of the PRF function.

Mike



>
> -Martin
>
>