Subject: Re: [TLS] PRF in 1.3

From: Henrik Grubbström <[email-masked]>
Date: Wed, 6 Aug 2014 13:43:15 +0200

On Wed, Jul 30, 2014 at 5:51 PM, Michael StJohns <[email-masked]> wrote:
> On 7/28/2014 4:24 PM, Dave Garrett wrote:
>>
>> https://github.com/tlswg/tls13-spec/issues/26
>>
[...]
> I don't believe this is the right place to start asking the questions.
> Instead, let's look at where the PRF is used and in what context, and then
> figure out whether or not what we have is good enough.

Agreed.

[...]
> So breaking it down:
>
> Is (1) secure enough to derive keys?   The construct used in TLS is similar
> to the section 5.2 construct of NIST SP800-108.  But the SP800 construct has
> one extra piece missing from this one - the L parameter which ensures that
> the key stream changes if the number of output bits change.  There's also
> expanded guidance on the context field - the equivalent values in TLS are
> currently just the client and server random.   I've got some issues with
> 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.

[...]
> The requirements for (2) (key not available until later) argues that the TLS
> PRF has to continue to be built on a hash function unless the data signed by
> (2) changes.  The discussion for (4) suggests that we can't just say that
> SHA256 will always be the value.

Agreed.

/grubba

-- 
Henrik Grubbström                                       [email-masked]
Roxen Internet Software AB                              [email-masked]

---

From: Michael StJohns <[email-masked]>
Date: Wed, 06 Aug 2014 14:57:58 -0400

> 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

---

From: [email-masked] (Martin Rex)
Date: Wed, 6 Aug 2014 21:11:22 +0200 (CEST)

Michael StJohns wrote:
[ Charset UTF-8 unsupported, converting... ]
> suite with a PRF P_SHA256 at not greater than 128 bits for TLS1.2 and 

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

---

From: Michael StJohns <[email-masked]>
Date: Wed, 06 Aug 2014 16:10:46 -0400

> 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

---

From: Andrey Jivsov <[email-masked]>
Date: Wed, 06 Aug 2014 22:37:27 -0700

On 08/06/2014 01:10 PM, Michael StJohns wrote:
> the HMAC (which is 256 bits for SHA256) unneedsderlying the PRF, but since

For the hash function collision over a handshake to be a problem there 
should to be a setting in which a collision of the hash output value 
over *any* two handshakes poses a problem.

Statements about *this* particular handshake still fall under MAC usage. 
This case seems to apply here because each peer is hashing "his" packets 
and that is the hash value that needs to match.