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