Re: [TLS] simplistic renego protection

It seems many of the drawbacks of tls-renegotiation-00 you mention 
are in fact addressed (to some degree) in version -01? (mainly
by including the "magic cipher suite") Compared to -01, what do
you think the main differences are?

Best regards,
Pasi
(not wearing any hats)

> -----Original Message-----
> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of
> ext Michael D'Errico
> Sent: 17 November, 2009 07:04
> To: tls@ietf.org
> Subject: Re: [TLS] simplistic renego protection
> 
> > 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.
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls