gnutls_safe_renegotiation_set?

[Simon Josefsson]

Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:

> On Mon, May 3, 2010 at 3:58 PM, Simon Josefsson <simon at josefsson.org> wrote:
>> The new gnutls_safe_renegotiation_set API doesn't seem to influence
>> rehandshakes -- i.e., I cannot first handshake successfully with the
>> extension, call the API with flag=0, and then do a rehandshake that does
>> not use the extension.  Is this intentional?
>
> Never thought of such usage of it. I see no reason to allow such
> behavior since it will only complicate code without offering new
> functionality or advantage.

Agreed, although it is useful to be able to self-test one possible
attack vector where the attacker negotiates the extension on initial
handshake but the later handshakes do not use the extension.

>> More generally, why do we need this API at all?  Isn't the natural thing
>> to use the priority strings to disable the extension?  Same question
>> about gnutls_safe_negotiation_set_initial.
>
> They are not really needed. We could remove them. They were left there
> to allow similar behavior with other functions that can also be set
> with priority strings.

I understand, but for new code it should be just as easy to use a
priority string function, and I see no disadvantage with requiring that.
This may even lead more projects to support priority strings which is a
good thing...  I believe having some projects begin to use the new two
APIs above would be bad: then they eventually will need to think about
user interfaces for enabling/disabling that know.  And priority strings
have already solved that.

I'll remove these two APIs in a few days unless I hear objections.

/Simon