Kyle Hamilton wrote:
> What I'm seeing here:
> 
> An implementation continues to be conformant to TLS even if the RI
> isn't sent.

Sure, but is it compliant with draft-ietf-tls-renegotiation?

I suggest that it shouldn't be.

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

What is the benefit to anyone of a patched server not replying with the
extension when it was specifically requested by the client?

Allowing that just adds (or multiplies) in another valid combination
that has to be regression tested.

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

Which a year from now ought to be "don't connect to servers who's admins
don't care enough to apply security patches in a year".

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

Agreed.

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

Why?

What if the client used the MCS flag for the initial handshake? How can
he send the verify_data if there's no RI in the second handshake?

If it must be restricted, I'd prefer that the MCS flag be allowed only
on initial hello and banned on renegotation handshakes.

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

Sure, but that's not a reason to not reply with RI when requested. It's
not a reason for the server to not tell the client that it is, in fact,
patched.

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

The client doesn't necessarily see the renegotiation, so it can't know
that it's not taking part in one.

> If
> it does not, the server will believe that it is an unpatched client
> and expect/accept only one negotiation.

If it's been patched and configured such that it talks to insecure clients.

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

Why should the client advertise that he's willing or not willing to
renegotiate? What if the API and existing application code defers that
decision until later?

A client app that is willing renegotiate only just after submitting an
HTTP request and if the user could possibly approve the client cert
request. Client certs could become enabled at any time and shouldn't
cause existing connections to break!

IMHO a patched client should always send the magic cipher suite so the
server can prevent MitM. That way you don't have to force the server
into making the difficult decision as to whether or not to join in on a
possibly-compromised connection.

- Marsh