Re: [TLS] simplistic renego protection

Pasi.Eronen@nokia.com wrote:
> 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?

If you include a magic cipher suite, then you don't need to send
*anything* else from client to server.  This is what the alternative
does that I implemented yesterday.  The contents of the extension do
not need to be transmitted over the wire since both peers know what
it should contain.  As long as that information gets added to the
Finished message calculation (true in both proposals), the security
hole is patched.

Plus I believe the magic cipher suite in RI-01 is only for fallback
behavior.  The very fact that fallback behavior needs to be even
considered in RI is a showstopper in my opinion.  The alternative
does not require any of that.

Mike

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