Re: [TLS] Analysis of Interop scenarios TLS extension RI w/MCSV

[Martin Rex <[e-mail]>]

Marsh Ray wrote:
> 
> > The purpose of the MCSV is:
> > 
> > - provide interop with installed base of old, extensions-intolerant 
> > servers (original&correct SSLv3 and "defective" TLSv1.0)
> >
> > - provide protection from downgrade attacks (extension-less 
> > ClientHello or SSLv2 ClientHello)
> > 
> > - provide protection in backwards interop scenarios (renegotiation 
> > requested by old servers).
> 
> It will never be safe to conduct renegotiation with a remote party in
> the absence of negotiated RI.

As I wrote a while ago, the name "TLS_RENEGO_PROTECTION_REQUEST"
was chosen _not_ as a requst for secure renegotiation (which it is NOT),
but as a request for _protection_ from the vulnerability through
old TLS renegotiation.

There are two different issues that the fix needs to provide:

  - secure renegotiation between updated clients and servers
    directly talking to each other

  - protection from MitM attacks in all 3 attack scenarios

  - protection from MitM attacks for communication between
    updated clients and updated servers even when both allow
    old renegotiation for backwards interop.

The secure renegotiation is provided by "authenticating" the
verify data from the previous finished messages.  TLS extension RI
performs the authentication with memcmp() on data exchanged
through a TLS extension in the renegotiation handshake.

The protection is provided through negotiating/signaling with the
peer that one is updated.

TLS extension RI does both with the same piece of data in the
handshake message (TLS extension RI), and it seems that some people
fail to understand the difference between the two things.



Previously, I wrote that draft-mrex-tls-secure-renegotiation-03.txt
is a "nanny spec", because it does _not_only_ describes how to perform
secure renegotiation, but it _also_ describes how to implement
backwards interop securely.  This discussion here sugggests that
this difference is unclear to at least some people, and therefore
should be better explained in the draft-ietf-tls-renegotiation-02
as well!



-Martin