[TLS] simplistic renego protection

[Martin Rex <[e-mail]>]

The most simplistic approch to renego protection is

   1. the client signals that it is patched through a fake
      ciphersuite ID in each ClientHello

   2. the client only supports secure renegotiation and
      secure renegotiation is specified to change the definition
      of the handshake message hash for renegotiation handshakes
      to include the verify_data of the client.finished and
      server.finished after the ServerHello.

Everything else is options for vendors and users.

If we do not provide a standardized signaling Server->Client in the
client hello, then it is not possible for the clients to offer
the option for insecure renegotiation (I have no idea whether such
a desire exists, but it might easily exist during transition).

With this simplistic approach, an MITM can not proxy a clients
initial handshake into an updated servers renegotiation, even
when the server still allows insecure renegotiation (e.g. during
the transition period).  


I really like to hear convincing arguments why we need the 
TLS extension in the renegotiation handshake, and why changing
the definition for the handshake message hash instead is not
a superior alternative.  In particular one that will grow
naturally into future TLS revisions.

-Martin