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

[Michael D'Errico <[e-mail]>]

There are a couple problems with changing the PRF:

    1)  there is no PRF in SSLv3
    2)  CertificateVerify is just a signature over the handshake messages

The idea of XOR'ing the verify_data with the master_secret would work
in SSLv3 (1), but would not help with (2).

Is (2) really important since the entire handshake is verified upon the
exchange of Finished messages?

Mike



David-Sarah Hopwood wrote:
> Blumenthal, Uri - 0662 - MITLL wrote:
>> Yes, previous_verify_data MUST be a part of the input to the PRF. What Yoav
>> Nir said (XOR-ing it with the master_secret), should work (out of hand -
>> anybody sees a problem with it?).
> 
> The previous_verify_data is not necessarily secret, so this requires the
> PRF to be secure against related-key attack. The particular PRFs used in
> SSLv3 and TLS 1.0 to 1.2 should be secure in that sense, but (if we
> decide to use this approach) I still prefer what I suggested before:
> 
>     verify_data =
>       PRF(master_secret, finished_label, Hash(handshake_messages)
>                                          + previous_verify_data)
>         [0..verify_data_length-1];
> 
> which uses the PRF in a more conventional way.