Re: [TLS] simplistic renego protection

[Stefan Santesson <[e-mail]>]

I started off thinking that the simplistic approach is too much of a quick
and dirty fix to be considered seriously, but I'm slowly beginning to like
it more and more.

I see some compelling arguments.

1) Is what has been stated before about the problems with extensions. If
there are a considerable amount of implementations where adding extension
support introduce significant problems, an extension less approach has
merit.

2) Is that we seem to agree that TLS 1.3 will have an updated finished
calculation anyway, not requiring the use of extensions. If we define that
"future" finished calculation now and use it in the simplistic approach,
then that would actually be closer to future versions of TLS, compared with
an extension approach.

If we consider the magic cipher suite signaling anyway in the extension
approach. In that case, what is the added value of using extensions over
just invoking the "future" and fixed finished calculation?

Is it necessary for the server to signal to the client that is supports the
upgraded finished calculation? It seems to me that an upgraded client could
calculate it both ways and detect the server's capability based on which
finished message the server sends. It may not be not optimal, but seems
feasible.


/Stefan



On 09-11-18 3:41 PM, "Simon Josefsson" <[e-mail]> wrote:

> <[e-mail]> 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: [e-mail] [mailto:[e-mail]] On Behalf Of
>>> ext Michael D'Errico
>>> Sent: 17 November, 2009 07:04
>>> To: [e-mail]
>>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/tls
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls