[gnutls-help] gnutls_dh_set_prime_bits question

[Ted Zlatanov]

On Mon, 01 Jul 2013 18:22:41 -0400 Daniel Kahn Gillmor <dkg at fifthhorseman.net> wrote: 

DKG> On 07/01/2013 05:50 PM, Ted Zlatanov wrote:
>> We understand it's insecure.  Our users have told us some servers won't
>> work without it.

DKG> I'd be curious to know which servers fail like this.  on those servers,
DKG> i'd say you'd be better off just not negotiating the any of the DHE
DKG> ciphersuites at all, rather than forcing the connection to a
DKG> trivially-crackable diffie-hellman exchange.

Here are the user reports about buggy servers and further discussions,
though in many cases they don't tell me the server name and I haven't
been asking.

http://lists.gnu.org/archive/html/bug-gnu-emacs/2011-07/msg00657.html
http://lists.gnu.org/archive/html/bug-gnu-emacs/2012-04/msg00761.html
http://thread.gmane.org/gmane.emacs.gnus.general/83413/focus=83441

On Tue, 02 Jul 2013 01:00:09 +0200 Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote: 

NM> The set_prime_bits sets the lowest acceptable threshold for a DHE prime.
NM> That is the actual security level. That unfortunately it is not
NM> negotiated in TLS, and thus the client can only drop the connection if
NM> the server goes lower than that threshold. A way to overcome that issue
NM> is instead of lowering the threshold, to retry a connection without DHE
NM> as Daniel mentioned.

(Assume we're upgrading Emacs to use the latest GnuTLS.)

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?

>> - how can we detect a server that demands 256 and renegotiate only for
>> those servers?

NM> You cannot. The way TLS is designed, you only get an error at the
NM> handshake.

>> We've been considering requiring GnuTLS 3.x but due to the platforms we
>> support in Emacs, that's not a simple decision.  Can you explain the
>> above questions and how they are different with ECDHE?  We plan to move
>> to 3.x fairly soon in any case, but knowing this will make my life easier.

NM> In ECDHE the curve (which is effectively the security level) is
NM> negotiated and thus has not the problems of DHE.

>> Will legacy servers (of which there are many, all critical to our users
>> apparently) work with ECDHE? 

NM> Unfortunately, I cannot know that. If they are very old servers most
NM> probably wouldn't support elliptic curves.

Well, there's always collateral damage.  We can tell our users "This
server is very old so it can't work by default.  You can set this
special workaround but only for a specific host name."  So I think it's
enough to detect this case, and in Emacs-land we can even auto-configure
so it only happens once.

Can we, then, have the following sequence:

- always connect with ECDHE, no DHE at all

- if ECDHE doesn't work, tell the user to configure
  some-special-variable for the target host to use DHE.  This will also
  let the user set the DHE min prime bits.  This code path does the
  dh_set_prime_bits in the priority string.

If so, could you tell me how to do the two steps?  I can't find examples
of this fallback in the manual in the repo or online, unfortunately.

(It would have been nice if the priority string could have the
dh_set_prime_bits control in it from the beginning.  I suggested packing
as much as possible in the priority string in the past, and still think
it's a good idea, essentially giving users a DSL to control GnuTLS
connection parameters.  Then the problem is reduced to keeping a special
priority string per host name, which is much more manageable for our
users.)

Ted