Yngve N. Pettersen wrote:
> 
> I also think that a client supporting RI which, due to fallback
> negotiation procedures, sent a MCSV-only handshake MUST, upon discovering
> that the server supports RI, terminate the connection (with a warning
> close notify, since it is not a real error), and re-establish the
> connection with a Client Hello that uses the RI extension.

I'm sorry, but I think that is a particularly bad idea, and completely
unnecessary.  In the IETF we are supposed to define and/or extend
protocols in a fashion that promotes interoperability.

The purpose of the MCSV is _NOT_ to prevent secure renegotiation in the
fashion you describe.  MCSV is the Client->Server signal that should
be both usable and non-disruptive to all existing SSLv3 and TLS
usage scenarios.

A server that receives a ClientHello with MCSV must treat
this exactly as if it had received an empty TLS extension RI.

The only thing that a server needs to know for the initial handshake
is that the client has been updated.  It is definitely not
necessary that the server asks the client to put a bow on it
and retry.  


If that handshake is an initial handshake for the server, then the
server must respond with a ServerHello containing an empty
TLS extension RI.

If the handshake is a renegotiation for the server, then the server
must abort the handshake with a fatal handshake alert.


Old servers that do _not_ need renegotiation do not need TLS extensions
either.  They will look purely for MCSV and return 7 extra bytes
on ServerHello following compression method -- aka "RI-minimal".


> 
> If this is implemented, this means that all patched servers will be TLS
> Extension tolerant, even if the only extension they understand is the RI
> Extension.

There is a misunderstanding about the term "Extension tolerant".
That is supposed to characterize the ClientHello forward compatibility
in the 18-Nov-1996 SSLv3 document, in TLSv1.0 (rfc-2246) and
TLSv1.1 (rfc-4346).  It means that the server receiving data after
compression_methods in ClientHello will tolerate the presence of
this data, but otherwise _completely_ ignore it.



The client MUST send MCSV on _every_ ClientHello, so that the
Client->Server signaling completely condition-free, which will
make it trivial to implement and robust.  This easy rule
completely obviates any talking about special cases or
attack scenario.  

Every TLS handshake requires an initial ClientHello, and if that
ClientHello always carries the Client->Server signal (which is
easy to accomplish for the MCSV and non-disruptive to existing
usage scenarios, then it will be completely impossible to
lure an updated client into an old renegotiation with an updated
server, no matter how willing client and server are to
perform backwards interoperable renegotiations with old peers.



-Martin