[Dovecot] 2048-bit Diffie-Hellman parameters
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
In recent years, there has been increased interest in DH especially in its ephemeral version (DHE) because it provides perfect forward secrecy. In that context, the use of 1024-bit parameters might not seem such a terrible idea: if someone cracks the ephemeral key then they will only gain access to the data exchanged during that particular session. Therefore, it might not be worth the effort to crack such a key. But this is certainly not the case for IMAPS: it is quite likely that the session data will include the user's credentials.
Am 24.09.2013 08:48, schrieb Marios Titas:
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
In recent years, there has been increased interest in DH especially in its ephemeral version (DHE) because it provides perfect forward secrecy. In that context, the use of 1024-bit parameters might not seem such a terrible idea: if someone cracks the ephemeral key then they will only gain access to the data exchanged during that particular session. Therefore, it might not be worth the effort to crack such a key. But this is certainly not the case for IMAPS: it is quite likely that the session data will include the user's credentials.
you may get problems with older mail clients , on smtp side i discovered i.e netscape 7 ist not able to handle stuff bigger then 1024 but some more configure options maybe fine ever
Best Regards MfG Robert Schetterer
-- [*] sys4 AG
http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
On 9/24/2013 3:05 AM, Robert Schetterer wrote:
you may get problems with older mail clients , on smtp side i discovered i.e netscape 7 ist not able to handle stuff bigger then 1024 but some more configure options maybe fine ever
Netscape 7.2 is *9* years old, 7.0 is *11* years old. I think I'd be right, in fact, there's no way I could be wrong, if I stated:
Anyone using 9-11 year old software is obviously not concerned about security.
-- Stan
Am 24.09.2013 11:32, schrieb Stan Hoeppner:
On 9/24/2013 3:05 AM, Robert Schetterer wrote:
you may get problems with older mail clients , on smtp side i discovered i.e netscape 7 ist not able to handle stuff bigger then 1024 but some more configure options maybe fine ever
Netscape 7.2 is *9* years old, 7.0 is *11* years old. I think I'd be right, in fact, there's no way I could be wrong, if I stated:
Anyone using 9-11 year old software is obviously not concerned about security.
however people still using it, and this was only some example ( there might be other mail stuff acting like this ), i agree your argument, i only want to warn about some support question might come up with more secure settings
Best Regards MfG Robert Schetterer
-- [*] sys4 AG
http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
On 9/24/2013 1:48 AM, 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...
Why play incremental tiddly-winks with the NSA? Go straight to 1048576 bit encryption. That'll surely keep them out. Oh, wait, all of your email leaves and arrives via public SMTP, which nobody encrypts...
NSA doesn't sniff the wire. They don't crack encryption. Neither are cost effective. They go straight to the source, intimidating the service provider into giving them the data, unencrypted. Or they don't get the data at all. So how does greater encryption help anyone "in light of recent events"?
-- Stan
Am 24.09.2013 11:21, schrieb Stan Hoeppner:
On 9/24/2013 1:48 AM, 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...
Why play incremental tiddly-winks with the NSA?
Go straight to 1048576 bit encryption.
is nothing else than a pointless polemic attitude
That'll surely keep them out. Oh, wait, all of your email leaves and arrives via public SMTP, which nobody encrypts...
maybe on your server, my logs showing the opposite and since the "smtp" are outgoing messages your conclusion of "nobody" is strange
cat maillog | grep smtp | grep -v smtpd | grep TLS | wc -l 12327
cat maillog | grep smtpd | grep TLS | wc -l 13350
cat maillog | grep smtp | grep -v smtpd | grep TLSv1.2 | wc -l 2603
cat maillog | grep smtpd | grep TLSv1.2 | wc -l 2219
On 9/24/2013 2:28 AM, Reindl Harald wrote:
maybe on your server, my logs showing the opposite and since the "smtp" are outgoing messages your conclusion of "nobody" is strange
cat maillog | grep smtp | grep -v smtpd | grep TLS | wc -l 12327
cat maillog | grep smtpd | grep TLS | wc -l 13350
cat maillog | grep smtp | grep -v smtpd | grep TLSv1.2 | wc -l 2603
cat maillog | grep smtpd | grep TLSv1.2 | wc -l 2219
This doesn't necessarily mean the encryption is effective at cloaking the data exchange. Remember:
Most admins who use TLS on their MTAs don't reject the transaction of the presented certificates FAIL to be validated against your local trust store's certificates. Unlike the error dialog boxes presented to the end user when a certificate fails to validate against its local trust store, these "error fallbacks" are "silent" and to most users, completely invisible. (Yes, I know most MTAs will log a TLS certificate failure in the headers, but we're talking about Lusers here, not readers of this list.) Failing certificate validity means it could be ANYONE's key/cert used to setup the ephemeral connection, and you can place no reliance on that channel being opaque to third-party scrutiny.
Even if you DO reject all failing certifcate trust-stores (on *ALL* MX hosts that receive/send mail), it's increasingly likely that one or more of those root certificates are compromised, either publicly(*) or secretly though some back-door arrangement with the NSA. The Big Ugly elephant in the room is the notion of the NSA having a certificate signing key for VeriSlime/GeoBust/et al so that they're free to use their own key + cert in a MITM interception, with the end user being none the wiser(**). Take a tally of the jurisdictions of the big root-level CAs. It's alarmingly AUSCANNZUKUS-centric.
Even with all of the above dealt with, the rush for people to use Diffie-Hellman "PFS" based on elliptic curves (EC) may be itself subject to additional problems based on revelations and leaks that suggest the NSA has been busy subverting various standards and publicly designed software reference implementations to weaken its security in ways to benefit them. In particular, Schneier and Bernstein feel very uneasy about the NIST specified parametres for the EC-based cryptographic algorithms. These aren't "tin foil hatters" or kooks.
To that end, there are proposals to adopt elliptic-curve parametres and methods that each and every generated public key maps to a valid EC point.
See:
https://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html#c1675929 http://cr.yp.to/talks/2013.05.31/slides-dan+tanja-20130531-4x3.pdf http://cr.yp.to/ecdh/curve25519-20060209.pdf
An Ivory Tower organisation with total control over the clients' and the servers' configurations can pin all of its certs + keys, and configure them to dump connections that fail to validate local trust stores.
This is an unfortunately very subtle and nuanced problem that defies mere "throwing more bits" at your key sizes.
And I would hope that the IQ and worldly mindsets of those generally reading this list have an appreciation for why retaining complete control and privilege within your organisation's end-to-end security is important, now more than ever. It has nothing to do with "I'm not doing anything wrong, so they can read all they want."
For an ISP or other provider with a "random" and "noisy" userbase with who-knows-what clients + OS/platform brain damage, the problem is probably intractable unless you accept that some users will be simply unable to access the services from some or all of their devices.
=R=
(*) Despite many compromised CAs (Certificate Authorities) being known publicly, I discover an annoying large number of improperly configured systems who accept these as valid. Maybe there are/were distros who incorrectly compiled lists of CAs and didn't remove those compromised CAs from the trust-store. Maybe they're out of date. Who knows why.
(**) If you "pin" various trust store certificates + keys, you can detect this when it occurs.
See: https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning
Zitat von Noel Butler noel.butler@ausics.net:
On Tue, 2013-09-24 at 04:21 -0500, Stan Hoeppner wrote:
NSA doesn't sniff the wire. They don't crack encryption. Neither are
somebody hasnt been paying attention
[OT] Why, they actually use the english TEMPORA to get the data, so at
least in part they don't sniff the wire...
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
On 24.9.2013, at 15.01, Ron Leach ronleach@tesco.net wrote:
I support the OP's suggestion. Could the Dovecot developer(s) consider adding support for longer key sizes?
My answer from a few days ago on a different thread: http://dovecot.org/list/dovecot/2013-September/092615.html
I'd like to ask a further related question, is it possible to run Dovecot with GNUTLS instead of OpenSSL?
It used to be, but GNUTLS kept changing API and Dovecot nowadays doesn't support it.
participants (9)
-
lst_hoe02＠kwsoft.de
-
Marios Titas
-
Noel Butler
-
Reindl Harald
-
Robert Schetterer
-
Robin
-
Ron Leach
-
Stan Hoeppner
-
Timo Sirainen