Re: [TLS] simplistic renego protection

<Pasi.Eronen@nokia.com> writes:

> 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?

As far as I can tell, -01 does not fix (*) the problem for
clients/servers that uses

   a) a SSLv3 implementation, or
   b) a original TLSv1 implementation (e.g., RFC 2246), or
   c) a TLSv1.1 implementation without support for extensions.

Providing a solution only for the latest version of TLS is akin to ask
people to upgrade to the latest release of a particular software rather
than provide a simple fix to the existing deployed software.

I'm hoping Martin will submit a draft on his ideas soon so we can
compare the two.

(*) Where "fix" means that TLS renegotiation works and is secure.

/Simon

> 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