[Dovecot] 2048-bit Diffie-Hellman parameters

[Ron Leach]

On 24/09/2013 07:48, Marios Titas wrote:

> Currently, dovecot generates two primes for Diffie-Hellman key
> exchanges: a 512-bit one and a 1024-bit one. In light of recent
> events, I think it would be wise to add support for 2048-bit primes as
> well, or even better, add a configuration option that lets the user
> select a file (or files) containing the DH parameters
>
> [snip]
> the case for IMAPS: it is
> quite likely that the session data will include the user's
> credentials.


Thank you for suggesting this and, in light of the discussion that has 
resulted from your post, may I describe our use-case in the hope it 
might help shed light on why this could be worthwhile?

Most of our work is subject to various non-disclosure obligations, and 
our staff work around the world, on short assignments of a few days, 
maybe a week or so, in countries who have various approaches and 
cultures in respect of confidentiality.  It is vital for us that 
remote access to our mail server does not leak the user logons, 
because then all previous (and future) mail could be read by strangers 
in that country, and indeed by strangers in any country onto which our 
logon credentials were passed.  To leak a private message is one 
thing, but to leak the whole mailboxes of all projects is something 
else completely.  Additionally, if mail user names are also system 
logins, the problem becomes even more serious.

Blackberry (in its Enterprise configuration) was thought to solve this 
use-case, though I've never known what cryptographic techniques RIM 
employ and, in any case, RIM has come under significant pressure from 
several countries and, we suspect, may no longer remain secure.  We'd 
prefer to employ strong Open Source components.

Though counter-party email travels in the clear over SMTP, we'd prefer 
that outbound email from staff (on assignment overseas) is sent from 
outbound mail servers in our own country (submitting via TLS, though 
not part of Dovecot, of course), and we'd prefer that inbound email, 
to the staff's MUA, is not sent in clear while they are on assignment. 
  Using IMAPS we can ensure that mail -> MUA is always encrypted.

A recent post on the OpenSSL list

http://www.mail-archive.com/openssl-users@openssl.org/msg71899.html

reveals that TLS evolution is being actively discussed with a view to 
using stronger cryptography, and that OpenSSL and GNUTLS are divergent 
at the moment (something I hadn't realised).  Within that exchange of 
views, the problem of assuring end-to-end strong security, due to use 
of older or non-compliant components, is mentioned but (sometimes) 
wrongly, in my view, as a reason not to make improvements (yet).  The 
(quite genuine) problem of end-to-end consistency can be solved, we 
feel, if each component is upgraded, so that sysadmins or end-users 
can select compatible building-blocks, including MUAs, when 
implementing their organisation's mail systems.

I support the OP's suggestion.  Could the Dovecot developer(s) 
consider adding support for longer key sizes?

I'd like to ask a further related question, is it possible to run 
Dovecot with GNUTLS instead of OpenSSL?  Even if it is not possible, I 
would still support the inclusion of more DH parameters so that 
Dovecot is 'OpenSSL ready' when OpenSSL does adopt stronger cipher or 
protocol choices.  I can sort out what MUAs we use, or move to.

regards, Ron