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

[Martin Rex <[e-mail]>]

David-Sarah Hopwood wrote:
> 
> 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.


I strongly recommend against such an approach.
It's going to be a big mess implementation-wise.

You'll have to keep double the state around in order to be able
to calculate the Server.Finished of the Renegotiation, and
then transfer shift the oldest verify_data out after Server.Finished.

It's more code, it doesn't address the CertificateVerify at all
and to interop-test this reliably, you will need to perform
at least two rengotiations on a communication channel to be
sure that the shifting of the Finished messages works correctly.

Most implementations that offer renegotiation do not have
usage scenarios to test dual-renegotiations, requiring additional
test tools to be built.

One of the reasons why I wanted to add  the verify_data early
into the handshake is that the session only needs to provide
room for one of them, making it much easier to implement
when you don't have to special case around while
calculating the finished messages and temporarilyy parking
of the new Client.Finished before the new Server.Finished processing
has completed.

I think that adding the Client.Finished.verify_data at the very
beginning of a renegotiation handshake message hash,  maybe even prefixed
with a bogus Finished message header 0x14 0x00 0x00 0x77 would
address the theoretical attack that you brought up.


-Martin