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

[Nelson B Bolyard <[e-mail]>]

>> On 11/26/09  12:23 , "David-Sarah Hopwood" <[e-mail]>
>> 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?).

I replied to that in another message, but yes, don't mix key and non-key
data together like that in the PRF definition.  If you want to XOR the
new data with something, or append it to something, do it with some other
non-key (and non-constant) data that is input to the PRF, or else plan to
replace hardware.

>>> 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.

This would be OK for HSMs.  It doesn't change the definition of PRF.
It doesn't combine key and non-key data in a common input.
It doesn't change constants that may be in silicon.

On 2009-11-26 14:38 PST, Yoav Nir wrote:

> I don't see why my suggestion doesn't hold for SSLv3 as well. Here's from
> the spec:
>
> enum { client(0x434C4E54), server(0x53525652) } Sender;
>
> struct {
>         opaque md5_hash[16];
>         opaque sha_hash[20];
> } Finished;
>
> md5_hash
>         MD5(master_secret + pad2 + MD5(handshake_messages +
>                 Sender + master_secret + pad1));
>
> sha_hash
>         SHA(master_secret + pad2 + SHA(handshake_messages +
>                 Sender + master_secret + pad1));
>
> So this could be changed in renegotiation to the following, or the Sender
> field could be replaced with the contents of the previous Finished
> message (it's like the finished label)
>
> enum { client(0x434C4E54), server(0x53525652) } Sender;
>
> struct {
>         opaque md5_hash[16];
>         opaque sha_hash[20];
> } Finished;
>
> md5_hash
>         MD5(master_secret^previous_Finished_message + pad2 +
>                 MD5(handshake_messages +
>                 Sender + master_secret + pad1));
>
> sha_hash
>         SHA(master_secret^previous_Finished_message + pad2 +
>                 SHA(handshake_messages +
>                 Sender + master_secret + pad1));

For hardware security modules that implement SSL3, that change means
replacing the HSM.  The only change you can make to the definitions of
md5_hash and sha_hash that won't require the hardware to be replaced is
to change the definition of "handshake_messages".  That means somehow
making the additional data part of the data stream that gets input into
that MD5 or SHA function before "Sender", perhaps as if it was a pseudo
handshake message.