Re: safe renegotiation bug?

[Simon Josefsson]

Nikos Mavrogiannopoulos <address@hidden> writes:

> Simon Josefsson wrote:
>
>>   GnuTLS supports the safe renegotiation extension.  The default
>>   behavior is as follows.  Clients will attempt to negotiate the safe
>>   renegotiation extension when talking to servers.  Servers will accept
>>   the extension when presented by clients.  Clients and servers will
>>   permit an initial handshake to complete even when the other side does
>>   not support the safe renegotiation extension.  Clients and servers
>>   will refuse renegotiation attempts when the extension has not been
>>   negotiated.
>> 
>> I don't think that is (especially last sentence) what is implemented
>> now.  I would prefer to implement what is described in that text
>> (because it seems to make sense to me), but we could change the text to
>> match what is implemented (more relaxed approach).
>
> I'd prefer to keep the current behavior because it allows clients to
> have a maximum compatibility when %UNSAFE_RENEGOTIATION is specified,
> which was my purpose of it. Maybe some other flag could be introduced
> such as %INITIAL_UNSAFE_RENEGOTIATION, but this can happen at any point
> later.

Then there is no way to make clients allow initial handshakes but
disallow renegotiations.  That goes against a RECOMMENDED in RFC 5746:

4.2.  Client Behavior: Legacy (Insecure) Renegotiation

   This text applies if the connection's "secure_renegotiation" flag is
   set to FALSE.

   It is possible that un-upgraded servers will request that the client
   renegotiate.  It is RECOMMENDED that clients refuse this
   renegotiation request.  Clients that do so MUST respond to such
   requests with a "no_renegotiation" alert (RFC 5246 requires this
   alert to be at the "warning" level).  It is possible that the
   apparently un-upgraded server is in fact an attacker who is then
   allowing the client to renegotiate with a different, legitimate,
   upgraded server.  If clients nevertheless choose to renegotiate, they
   MUST behave as described below.

I would prefer a good reason to do something like that.

I don't understand your "because it allows clients to have a maximum
compatibility when %UNSAFE_RENEGOTIATION is specified".  Changing the
_default_ behaviour to follow the RFCs recommendation would not change
what happens when %UNSAFE_RENEGOTIATION is specified.  And indeed, with
%UNSAFE_RENEGOTIATION clients do have maximum compatibility already.
Could you clarify what you meant here?

/Simon