safe renegotiation bug?

[Nikos Mavrogiannopoulos]

Simon Josefsson wrote:

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

I mean that the default now for the client is %UNSAFE_RENEGOTIATION. As
far as I understand what you propose is to add an extra level for the
client that allows initial negotiation but not subsequent ones. Am I right?

To be honest I'd prefer to modify unsafe renegotiation to do what you
propose rather than adding an extra level. The code getting more and
more complicated as well as the behavior. It might be better to have few
easily explained states, rather than a bunch. With this change clients
using gnutls would need to specify %DISABLE_SAFE_RENEGOTIATION to have
the compatibility behavior (which is not so good but one has to draw a
line somewhere between keeping things simple and supporting everything).

So which solution do you prefer?


regards,
Nikos