What I'm seeing here:

An implementation continues to be conformant to TLS even if the RI
isn't sent.  If a client doesn't send the RI (either cipher suite flag
or extension), the server can't send the RI extension back (as it's a
violation of TLS 1.2 for a server to send an unsolicited extension).
If a client does send the RI cipherflag or extension, the server may
send back the RI reply, or (if its security policy prohibits
renegotiation -- to reduce the possible impact of large numbers of
reneg's overwhelming any crypto implementation, or because it's known
that client certificates are never going to be solicited by the
server, to name a couple of possible reasons) it may choose not to
reply with the extension.

In the event that the RI client doesn't receive the extension that it
solicited back from the server, it treats it as a non-RI server and
proceeds according to its own security policy.

(It goes without saying that the peers' security policies must have
some compatibility -- FIPS 140-2 validated TLS implementations already
can't talk to implementations that don't have any FIPS-approved
algorithms, so there's no reason to worry about this.)

On Mon, Nov 30, 2009 at 8:31 AM, Marsh Ray <marsh@extendedsubset.com> wrote:
>
>>    TLS clients which support this draft MUST generate either the
>>
>>    "renegotiation_info" extension or the TLS_RENEGO_PROTECTION_REQUEST
>>    cipher suite with every ClientHello.
>
> Can they generate both?
>
> If not, what does the server do if he receives both?

I suggest the wording 'MUST generate either or both of the RI
extension or the TLS_RENEGO_PROTECTION_REQUEST cipher suite flag with
every ClientHello.  If the client requests renegotiation, it must do
so with the same mechanism(s) that it used during the initial
ClientHello -- e.g. if the client uses the RI extension without the
cipher suite flag, then ClientHello handshake messages used for
renegotiation must not contain the cipher suite flag.'

>>    Existing implementations which do not support this extension are
>>    widely deployed and in general must interoperate with newer
>>    implementations which do support it.  This section describes
>
> s/must/need to/ to avoid confusion with MUST.

Agreed.

>
>>    If a client offers the "renegotiation_info" extension or the
>>    TLS_RENEGO_PROTECTION_REQUEST cipher suite and the server does not
>>    reply with "renegotiation_info" in the ServerHello, then this
>>    indicates that the server either does not support secure
>>    renegotiation or is unwilling to use it.
>
> Is it allowed for a patched server to be "unwilling"?
>
> If not, drop the "or is unwilling to use it" lest it give the impression
> that such behavior is condoned.

Above, I've suggested a couple of potential reasons why a server
(which knows about the renegotiation security hole) might simply
disable renegotiation entirely.

>>    If the client does not offer the "renegotiation_info" extension or
>>    the TLS_RENEGO_PROTECTION_REQUEST cipher suite then this indicates
>>    that the client does not support secure renegotiation or is unwilling
>>    to use it.  However, because the above attack looks like two
>
> Again, is it allowed for a client to be conformant to this spec and
> still not send either the extension or magic cipher suite value?
>
> - Marsh

A client may be conformant to this specification without sending
either the RI ext or the cipher suite flag, if it knows that it will
not perform or accept any requests to perform any renegotiations.  If
it does not, the server will believe that it is an unpatched client
and expect/accept only one negotiation.  Why indicate your willingness
to do something that you're not willing to do later anyway?

I'd suggest adding wording to this effect, suggesting that
implementations SHOULD offer this extension only if they're willing to
accept renegotiations.  (Local security policies may include "all
traffic that goes over the internet must appear as though it's coming
from servers that will renegotiate" -- if only as a prophylactic
against someone doing deep packet scanning and seeing a potentially
insecure server for later attack attempts.)

-Kyle H