Re: [Cfrg] TLS PRF security proof?

[Jakob Breier <[e-mail]>]

Hi,

On 10.07.2014 05:16, Andy Lutomirski wrote:
> On Wed, Jul 9, 2014 at 8:05 PM, Watson Ladd <[e-mail]> wrote:
>> On Wed, Jul 9, 2014 at 7:50 PM, Andy Lutomirski <[e-mail]> wrote:
>>> On Wed, Jul 9, 2014 at 6:52 PM, Watson Ladd <[e-mail]> wrote:
>>>
>>>> Without the salt argument the result is simply H(stuff), which is
>>>> supposed to be fine for any reasonable choice of H.
>>> If stuff is (party A data | party B data) and party A gets to choose
>>> all of its data offline, then this isn't so appealing for common
>>> choices of H.
>> Why not? Is there a weakness of SHA256 I'm unaware of? If you need
>> signatures, you need collision resistant hash functions.
>> All uses of SHA1 and MD5 need to be ended ASAP: Microsoft has already
>> begun this process.
> Suppose that party A is malicious and they can find "party A data 1"
> and "party A data 2" that collide.  I can imagine protocols in which
> this violates one of the assumptions of the protocol.
>
> If you allow party A to spend an extremely long time precomputing
> something *before starting the protocol*, I'd like the protocol to
> remain reasonably secure.  Hashes with unnecessarily small internal
> state violate this.

If internal state size is your problem you can always use Sha512 or 
Sha3-512 for an intended collision resistance of 256bit.

But I find your argument much more compelling in the context of 
deteriorating hash functions, like MD5. Of course you wouldn't use MD5 
for new protocols, nonetheless it provides a nice case study for how the 
Sha2 and Sha3 family might break down with future cryptanalysis. 
Specifically while MD5 is no longer collision resistant, it is still 
preimage resistant and target collision resistant / UOWHF (in the sense 
that the random value is prefixed to the message).


On 09.07.2014 17:28, Paul Hoffman wrote:
> On Jul 9, 2014, at 8:18 AM, Andy Lutomirski<[e-mail]>  wrote:
>
>> >I can't speak for the TLS WG, but from my own perspective, I have
>> >three problems with HDKF:
>> >
>> >1. HKDF is parametrized by a hash.  What hash should people use?
> Any one that has no known weakening of preimage resistance. That is: nearly any of them.

Which brings me back to RFC 5869 in the use case of PRFs for protocols 
like TLS. If you want to assure your handshake was not tampered with, 
for example in a downgrade attack, and then put the whole handshake into 
the PRF/KDF (in addition to the Diffi-Hellman result or some other 
secret) you will at least need collision resistance of the KDF. HKDF was 
not analyzed under this setting (as far as I can tell from Definition 7 
of the accompanying paper) and the explanations in the RFC do not help 
you decide with which hash functions it is secure then.

It would be nice to only rely on target collision resistance and 
preimage resistance instead of full collision resistance of the hash 
function, and for right choices of the salt this would be possible for 
HKDF, too. For example if after the handshake an additional random from 
each of the parties is exchanged and the concatenation is used as the 
salt. I don't see how it would be feasible without at least one further 
message transfer, though, so it it's likely not worth the additional costs.

Regards,
Jakob Breier