Re: safe renegotiation: confirming consensus

[Tomas Hoger]

On Mon, 03 May 2010 16:28:32 +0200 Simon Josefsson
<address@hidden> wrote:

> Client behaviour:

[ ... ]

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

Both OpenSSL and NSS allow upgraded clients to connect to unupgraded
servers by default.

OpenSSL also allows upgraded clients to renegotiate with unupgraded
servers, see:
http://www.openssl.org/docs/ssl/SSL_CTX_set_options.html#SECURE_RENEGOTIATION

NSS does not allow upgraded clients to renegotiate with unupgraded
servers, but afaik both firefox and chromium allow renegotiation for
now.  This documents what options NSS offers:
https://developer.mozilla.org/NSS_3.12.6_release_notes

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

Both OpenSSL and NSS servers behave like this by default.

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

Something like this may be desired when the default for servers changes
to require safe initial negotiation in the future.
%{,UN}SAFE_RENEGOTIATION do not seem to allow specifying current
default behavior explicitly. Can it be less confusing to have
%{,UN}SAFE_RENEGOTIATION and %{,UN}SAFE_INITIAL_NEGOTIATION, with
defaults for client/server set in gnutls_init?

th.