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

[David-Sarah Hopwood <[e-mail]>]

Yoav Nir wrote:
> On Nov 26, 2009, at 8:11 PM, Blumenthal, Uri - 0662 - MITLL wrote:
>> 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?).
>>>
>>> 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 no longer think we should use this approach; the arguments in favour
of encoding the previous_verify_data in handshake_messages (see below)
are compelling.

[reordered]
>> As for SSLv3 - SMNP (Simply Not My Problem :). Would be nice to
>> address it as well, but I'd rather not bend over backwards to also
>> fix SSLv3.

SSLv3 is easy enough to fix without bending over backwards.

> I don't see why my suggestion [XORing the master_secret with the
> previous_verify_data when computing the new hashes] doesn't hold for
> SSLv3 as well.

It does, but the specification complexity is on the high side, given that
the computations would need to be spelled out for SSLv3 and TLS separately,
as well as changing CertificateVerify. Nelson's point about hardware
security modules is another reason not to do this.

Adding the previous_verify_data into handshake_messages is preferable
because:
 - it treats SSLv3 and TLS entirely uniformly;
 - there is no problem with hardware security modules;
 - the use of hashing APIs is unchanged (unlike the suggestion to
   chain all messages in the previous session before those in the
   current session);
 - it automatically causes the previous_verify_data to be included
   in the data signed by CertificateVerify, when used.

The obvious place to put it is just after ServerHello, since that is
before CertificateVerify and is the first point at which both sides
know that this session is renegotiated.

The theoretical attacks that I was worried about are solved by using
the encoding starting with bytes {20, 0, 0, 0} described in my
followup to Eric Rescorla (subject "Verify data in the RI extension" --
it doesn't seem to be in the archive yet).

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com