Re: [TLS] Quest for Unified Solution to TLS Renegotiation

[Marsh Ray <[e-mail]>]

David-Sarah Hopwood wrote:
> Michael D'Errico wrote:
>>> Eric Rescorla wrote:
>>>
>>>>>    3) Incorporate previous verify_data into Finished calc.
>>>> I'm not happy with this, actually.
>> Would this work:
>>
>>      Finished  =  verify_data  XOR  previous_verify_data
> 
> No. The previous_verify_data has to be in the input to the PRF
> that also depends on the master_secret. If you just XOR it to
> the output, then the attacker doesn't need to know the master_secret
> in order to change the unmodified Finished to the modified one.

If I understand it correctly, Mitm could decrypt the renegotiated
Finished message record, modify it, and re-encrypt it. Effectively this
means the authentication and integrity guarantees on protocol could be
no stronger than the encryption. That could be a significant weakening
of the protocol's security.

Another attack would require Mitm to arrange for an arbitrary Finished
message on the previous session.

In order to do that he would have to
a) know ahead of time what value to construct and
b) succeed at a first preimage attack on the hash function represented
by 12 bytes from the PRF

Pulling off (a) would be hard because of the unpredictable random_data
bytes in the other side's Hello message.

(b) would mean the protocol was so broken that he wouldn't need
renegotiation to compromise it. It's worth noting here that this hash
output is 96 bits. The NIST hash selection process for the successor to
SHA requires a minimum output size of 224 bits.

- Marsh