[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gnutls_safe_renegotiation_set?
From: |
Simon Josefsson |
Subject: |
Re: gnutls_safe_renegotiation_set? |
Date: |
Mon, 03 May 2010 16:33:57 +0200 |
User-agent: |
Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) |
Nikos Mavrogiannopoulos <address@hidden> writes:
> On Mon, May 3, 2010 at 3:58 PM, Simon Josefsson <address@hidden> 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