Re: [TLS] simplistic renego protection

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

> If you want your alternative proposal to be considered, submit an 
> Internet draft and get some running code and feedback from 
> implementations showing your proposal would deploy protection to more 
> users than draft-rescorla-tls-renegotiation-00.  Then you may sway 
> people to your viewpoint.

Here is how draft-rescorla-tls-renegotiation-00 fails to protect the
most people:

   - there are so many interoperability problems with TLS extensions
     that even the author of the draft suggests that a "lenient"[*]
     client not send the extension on its initial connection

   - there will be a transition period where some servers absolutely
     need to continue allowing unpatched clients to perform the current
     vulnerable renegotiation.

   - a lenient client's handshake without the RI extension looks just
     like an unpatched client that these unfortunate servers need to
     continue supporting

   - a man-in-the-middle can take advantage of these three points to
     victimize a patched client talking to a patched server!

Just today many of us have converged on an alternate solution that does
not have this serious problem.  Instead of using extensions with all
the myriad problems, the only bits-on-the-wire change is to include a
single special cipher suite that signals to the server that the client
wishes to use a new calculation of the Finished messages that includes
the verify_data from the previous handshake.  I suggested that an alert
message could be used for the server to acknowledge back to the client.

This uses only features that are present in SSLv3, so it is much more
likely to be implemented quickly and correctly, and it does not require
implementations to add any code for extension processing if they don't
already support extensions.  It also protects the lenient client and
unfortunate servers above since there is no reason not to include the
magic cipher suite in ALL handshakes.

Here is a pointer to a summary of the proposal:

   http://www.ietf.org/mail-archive/web/tls/current/msg04393.html

I am not a spec. writer, so someone else should write it up.  If it is
adopted I will implement it in my test server in short order for anyone
to test against.

Mike


[*] a lenient client is one that would connect to any server regardless
of whether it is patched or not.  Since there is a not-insignificant
chance that a server will barf on the use of extensions, and the lenient
client wouldn't abort the handshake even if the extension is not
returned by the server, it is less painful to just do what's always
been done.