[TLS] Another critical problem with RI

[Michael D'Errico <mike-list at pobox.com>]

Here is yet another reason to reject Renegotiation_Info:

The security of RI relies on implementations verifying that the data
carried in the extension is correct.  It is possible for implementors
to get this wrong.  A client or server could correctly get all of the
mechanics of sending and receiving the extension working but fail to
actually compare what they received to the old verify_data.  Looking
at the bits-on-the-wire it will not be possible to tell that a client
or server is broken in this way.  These broken implementations will
be able to perform initial connections and renegotiations.  Such a
broken client paired with a broken server would still be vulnerable
to a MitM attack.

Changing the Finished message calculation, on the other hand, is fool-
proof.  Either you add the old verify_data to the handshake messages
or you don't.  If you don't, then handshakes will fail regularly[*]
and the problem will be noticed and fixed.

Note that adding the verify_data to the ClientHello.random and
ServerHello.random suffers from this same problem.

Mike

[*] To make this even more fool-proof, I suggest making sure that the
data added to the handshake message stream is never empty (i.e. as it
would be on an initial handshake in Martin's proposal); this can be
easily done by including length byte(s) or even a single fixed byte.