[gnutls-help] gnutls_dh_set_prime_bits question

[Ted Zlatanov]

On Tue, 09 Jul 2013 15:46:56 +0200 Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote: 

NM> On 07/09/2013 03:13 PM, Ted Zlatanov wrote:
NM> On 07/02/2013 08:31 PM, Ted Zlatanov wrote:
>>>> I think negotiating the connection twice is unacceptable for
>>>> performance.  We have to find a way to do it in one attempt, even if the
>>>> user has to configure something about the exceptional servers.  Can we
>>>> always try ECDHE and only do DHE if the user tells us so?
>> 
NM> You can always disable DHE. That way ECDHE will be negotiated with RSA
NM> as fallback.
>> 
>> I'm sorry to keep asking, but I can't find this explicitly in the
>> manual.  Maybe I'm looking in the wrong places.  From
>> http://gnutls.org/manual/html_node/Priority-Strings.html I am guessing
>> that:
>> 
>> 1) Including ANON-ECDH enables ECDHE

NM> No. Anon-ECDH is for anonymous authentication. ECDHE-RSA and ECDHE-ECDSA
NM> are for certificate authentication and are already enabled by NORMAL.

>> 2) !DHE-RSA:!DHE-DSS disables DHE (not sure if DHE-RSA should be enabled for us)

NM> Correct.

>> 3) NORMAL enables DHE and ECDHE

NM> Yes.

>> It would be very nice if the initial keywords' description in that
>> documentation page actually showed what's enabled by each one,
>> especially "NORMAL".

NM> Indeed, this may be useful. I should update that at some time.
NM> You can see that using gnutls-cli -l --priority xxx.

>> I also can't tell how to set the DH minimum prime bits in a priority
>> string, if that's possible at all.

NM> The initial keyword of the string sets the acceptable security level,
NM> which at some later point it is translated on the minimum size of the
NM> prime. Currently normal sets the value GNUTLS_SEC_PARAM_VERY_WEAK, which
NM> is 727 bits of a prime. SECURE128 and 256 increase that value.

NM> The idea was to have some consistency in the security levels, but given
NM> the security levels offered by real-world servers, that would take some
NM> time to occur.

>> I can write additions to the manual to explain any of the above if you
>> think they are needed.

NM> That would be really helpful.

Hi Nikos,

I was about to submit a patch against the manual based on this e-mail
from July and wanted to quickly check if the answers to (1), (2), (3)
have changed (since I know there have been some issues with EC since
then).

Ted