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

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

Martin Rex wrote:
> David-Sarah Hopwood wrote:
>> The old verify_data should not just be appended to the handshake_messages
>> without any further encoding, though, because it might match the bytes
>> of some valid handshake message. In that case, there is the possibility
>> that a MITM might insert the old verify_data into the stream sent to
>> one peer, as though it were a handshake message. If that peer is using
>> the unmodified Finished computation (either because it is unpatched or
>> it is doing an initial handshake), then it may end up computing the same
>> Finished hash as the other peer that is using the modified computation.
>>
>> I haven't gone through the details of this attack thoroughly enough
>> to be sure it will work, but it is too near working for comfort.
> 
> There are no handshake messages after finished.

That's not relevant.

> You forgot the signaling in the ServerHello and ClientHello
> that is also covered by the handshake message hash.

It appears that
<http://www.ietf.org/id/draft-mrex-tls-secure-renegotiation-01.txt>
is indeed not vulnerable, because of the requirement that allow_old_renego
MUST be set to false when the peer is found not to be updated. Previous
summaries of the proposal on the list were not clear about this; they
implied that updating the finished hash would automatically make
renegotiations with an unupdated peer fail.

Note, however, that (unless it is changed as I suggested) this
contradicts one of the claimed advantages over RI.

> the verify_data should be added directly following ServerHello.

Yes, that's where the attacker would send it. (You may have been
confused by my choice of the word "appended"; I meant "appended at
the point where the it is known that the new Finished computation
will be used".)

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