safe renegotiation: confirming consensus

[Nikos Mavrogiannopoulos]

Simon Josefsson wrote:
> Based on recent discussion, here is my perception of what I believe
> would be the best to implement.  Note that this is not what is
> implemented today, so some of the priority strings below have slightly
> different meaning now.

I don't understand. Why we go again through this? What is the problem
with the current implementation that needs to be fixed? The only thing I
got from the previous e-mails are about the default server behavior.

> Client behaviour:
> 
>   Client sends the extension by default.  Can be disabled with
>   %DISABLE_SAFE_RENEGOTIATION priority string.
>   Clients will talk to servers that do not support the extension by
>   default, but will refuse any rehandshake attempts against those
>   servers.  This would cause operational problems: can we confirm that
>   NSS and/or OpenSSL clients behave like this?  Otherwise we probably
>   shouldn't enable it.

I'd be happy if this option is not documented at all. It is available
for testing purposes only and it is mentioned in the documentation as
such. Typical applications shouldn't use this flag.

>   When %SAFE_RENEGOTIATION is used, the client will never talk to a
>   server that doesn't support the extension.
> 
>   When %UNSAFE_RENEGOTIATION is used, the client will talk to servers
>   that doesn't support the extension including re-handshakes.
As documented now.


> Server behaviour:
>   Servers will accept connections from clients that do not support the
>   extension, but will refuse any rehandshake attempts with that client.
>   This is the important behaviour that closes the security problem for
>   GnuTLS servers.  I believe we have confirmed that OpenSSL servers will
>   behave like this. (1)
This is the SAFE_RENEGOTIATION flag now. Why remove the flag for it?

>   When %SAFE_RENEGOTIATION is used, the server will never talk to anyone
>   who doesn't support the extension. (2)
>   When %UNSAFE_RENEGOTIATION is used, the server will talk to clients
>   that doesn't support the extension including re-handshakes.
> 
>   The %INITIAL_SAFE_RENEGOTIATION is not needed anymore can be removed.
It is needed since this flag distinguishes the case (1) from case (2).

IMO the flag SAFE_RENEGOTIATION is more clear in what it does now. It
does safe renegotiation only. Initial negotiation is safe anyway thus it
doesn't add in security to require the extension.

> Q: should SECURE imply %SAFE_RENEGOTIATION?

No. The keywords SECURE/NORMAL/etc apply to ciphersuites.

> Q: do we need a priority string to describe the default behaviour?  For
> example %PARTIAL_RENEGOTIATION?  The reason would if you want to say
> something like SECURE:%PARTIAL_RENEGOTIATION to get high-security
> defaults but still support renegotiation using our normal behaviour wrt
> renegotiation.

Why not use INITIAL_SAFE_RENEGOTIATION and SAFE_RENEGOTIATION? I have no
problem changing the names, but what why do that? Aren't they clear? Are
they hard to understand (may be).

> I'm not sure the terms of the priority strings are the best, the RFC
> doesn't use the concept "safe renegotiation", does it?

It mentions renegotiation indication, which is worse as a term to
indicate a security fix.



regards,
Nikos