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