[gnutls-help] gnutls_dh_set_prime_bits question

[Nikos Mavrogiannopoulos]

On Sat, 2013-12-21 at 16:17 -0500, Ted Zlatanov wrote:
> On Tue, 09 Jul 2013 15:46:56 +0200 Nikos Mavrogiannopoulos <nmav at gnutls.org> 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.

Hello,
 The above still holds.

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

Correct.

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

Still there.

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

Still holds.

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

What issues are you referring to?

regards,
Nikos