safe renegotiation in client side

[Simon Josefsson]

Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:

> Given your experiences (as system packager, user, implementor or so),
> what do you think is the adoption of priority strings in programs?

I find it quite rare still, sadly.  I don't recall _any_ application
that allows users to configure priority strings per-IP address, which
would be the optimal approach.

I believe it would be painful to release a GnuTLS client that refused to
talk to non-patched servers.  If I understand correctly, it doesn't
improve anything for the client to behave like that, it is only the
server that is protected by such a client.  Thus, I think we should let
servers require patched clients when it makes sense, and otherwise be
more lenient on the client side.

I wish there was an easy way to warn the user somehow though.  Syslog a
message with the server hostname?  Should we add a function so that
applications can find out if a session is potentially insecure due to
this threat?  Any way to make it less specific to renegotiation issues?
We have other areas that users may want to be aware of too -- e.g., if
the connection is using a weak cipher, if the connection is not using
DHE, etc...  OTOH maybe this is overkill.  Power-users can use
gnutls-cli to find out manually, and other users are probably fine with
a lenient default anyway.

/Simon