bug#11267: bug#15057: 24.3.50; TLS error with reasonably high gnutls-min-prime-bits, bug#11267: 24.0.95; gnutls.c: [0] (Emacs) fatal error: The Diffie-Hellman prime sent by the server is not acceptable (not long enough).

[Ted Zlatanov]

On Mon, 10 Feb 2014 09:28:09 +0100 Nikos Mavrogiannopoulos 
<n.mavrogiannopoulos@gmail.com> wrote: 

NM> On Mon, Feb 10, 2014 at 4:06 AM, Roland Winkler <winkler@gnu.org> wrote:

>> I am still a bit confused concerning a "reasonable minimal value"
>> for gnutls-min-prime-bits.  Is 256 a value that I can feel
>> comfortable about?

NM> No. 256-bit DH is a bit harder than rot13 as encryption. I'd suggest
NM> not to set the minimum acceptable size and let gnutls decide instead.
NM> For broken servers that use very small sizes, you could disable the
NM> DHE ciphersuites as described in the previous mails.

On Sun, 09 Feb 2014 18:58:34 -0800 Lars Ingebrigtsen <larsi@gnus.org> wrote: 

LI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> See http://thread.gmane.org/gmane.network.gnutls.general/3181/focus=3299
>> 
>> Try, first of all, appending `!DHE-RSA:!DHE-DSS' to your GnuTLS priority
>> string to disable DHE.  ECDHE will not have the minimum bits message,
>> ever, IIUC.

LI> But aren't there lots of (or some) servers that only supports DHE and
LI> not ECDHE?

There's no way to know until you connect, that's the heart of the
problem.  So IIUC you'd have to either be potentially insecure all the
time (DHE enabled) or potentially fail connecting to some servers.

I think the latter is the better option as a default, as long as we make
it clear (not in a *GnuTLS log* buffer but with `message' so it shows up
in the echo region and in STDERR in batch mode) that

* the connection was rejected because the remote requires a lower level
of security

* how to try allowing the less-secure connection (perhaps a simple
command to automate this, or even a clickable button, would be nicer
than asking the user to `customize-variable').  The original discussion
sort of settled on magically reopening the connection with less security
but I think that might be a disservice to the users.

* why it's smarter to ask the server admin to upgrade their TLS
implementation

Fitting all of that in a short readable message might be a challenge,
hence the button suggestion, but that's not ideal either.

Ted