Re: [TLS] simplistic renego protection

Stefan Santesson wrote:
> 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.

Agreed.

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

This is one of the reasons I so dislike RI.  The alternative presented
modifies the Finished calculation in a way that is forward-compatible;
it can be the default for future TLS versions, and that is the way it
is implemented in my code now.  If people don't like adding the previous
verify_data to the stream of handshake messages so it gets hashed along
with the rest, then please suggest a better way.

One note: at first I didn't like the idea of inserting the verify_data
immediately after the ServerHello, but when I implemented it, that was
actually the most natural place to put it.

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

None as far as I can tell.

Mike

> 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" <simon@josefsson.org> wrote:
> 
>> <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
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
> 
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 