Re: [TLS] PRF in 1.3

[[e-mail] (Martin Rex)]

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.

-Martin