[TLS] Quest for Unified Solution to TLS Renegotiation

[Michael D'Errico <[e-mail]>]

I think that it would be good to find a unified solution that
everybody is happy with, and believe that this may be it:


   1) Client-to-Server signalling can be done in either of
      two ways:

      A) an empty Secure_Renegotiation (SR) extension, or
      B) a "magic" cipher suite

   2) Server-to-Client signal is always an empty SR extension

   3) Incorporate previous verify_data into Finished calc.


The particulars:

A client that currently sends any other extensions MUST also
send the empty SR extension.

A client that currently does not send any extensions MAY send
the empty SR extension, or MAY send the magic cipher suite.

In response to either 1A or 1B, the server responds with an
empty SR extension.  The only ugliness is this apparently-
unsolicited extension returned by the server in response to
the magic cipher suite.  I used to be against this, but have
since decided that it is no more ugly than flipping a version
bit or any of the other ideas.

It remains to be decided if adding the verify_data to the
handshake message stream is the right way to do (3), or if
changing the PRF in some way is better, such as changing the
seed to be the handshake message hash appended with the old
verify_data, or some other method.



Benefits:

All versions including SSLv3 are fixed and able to renegotiate
safely.

This is entirely backward-compatible with SSLv3, even SSLv2
ClientHello.  It is better than RI because when the magic
cipher suite is used there, the server can not check the
verify_data from the client (since it is not sent), so it
can not renegotiate with those old clients at all.

Using an empty extension is much more lightweight a use of
extensions than RI since there is no need to pack the verify_
data into it when sending, or to extract the data when
receiving.

Clients that don't want to add full support for extensions do
not need to -- they can just check for the existence of the
empty SR extension which is a fixed 6-byte string.


I would fully support this "new"[*] solution.  Anybody else?

Mike


[*] I do not remember who initially came up with each of the
ideas in this solution; it was truly a team effort.