Is Diffie-Hellman needed on a modern new dovecot setup?
ssl_dh is empty by default. Both ssl_cert and ssl_key on my setup are pointing to let's encrypt certs.
However i see Diffie-Hellman related warnings in logs: dovecot[1073]: imap-login: Error: Diffie-Hellman key exchange requested, but no DH parameters provided. Set ssl_dh=
Am i causing issues for some users by not setting up ssl_dh or is this something being phased out?
And follow up question;
The docs say you are encouraged to disable non-ECC DH algorithms completely. However i didn't see anything on that same page explaining how to go about doing that.
Can someone point me to something explaining what that means and how to go about doing it?
I want better explanations of the maths.
If RSA and DSA algorithms based on standard arithmetic exponentiation modulo the product of two large primes are "deprecated" -- that means that there have been or are expected to be major mathematical and algorithmic advances in factoring large integers. The maths are easy for those algorithms, whereas the ECC algorithms are based on very advanced maths which aren't being explained satisfactorily to the general public, with $1,000,000 USD prizes still out for the so-called Birch and Swinnerton-Dyer conjecture and the Riemann Hypothesis, which might be more applicable to factoring the "semi-primes" of RSA/DSA/DH type algorithms.
On January 10, 2022 7:12:40 AM AKST, dovecot@ptld.com wrote:
And follow up question;
The docs say you are encouraged to disable non-ECC DH algorithms completely. However i didn't see anything on that same page explaining how to go about doing that.
Can someone point me to something explaining what that means and how to go about doing it?
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
dovecot@ptld.com writes:
Is Diffie-Hellman needed on a modern new dovecot setup?
Needed? Strictly speaking, probably not. Most clients will fall back to RSA, although some security hardened clients might refuse if you don't have non-RSA ciphers.
However i see Diffie-Hellman related warnings in logs: dovecot[1073]: imap-login: Error: Diffie-Hellman key exchange requested, but no DH parameters provided. Set ssl_dh=
Am i causing issues for some users by not setting up ssl_dh or is this something being phased out?
It just something you have to do to start using DH, analogous to having to generate 2 primes when using RSA. If you don't set it up, DH can't be used.
And follow up question;
The docs say you are encouraged to disable non-ECC DH algorithms completely. However i didn't see anything on that same page explaining how to go about doing that.
Can someone point me to something explaining what that means and how to go about doing it?
You have to specify your own ciphersuite via the ssl_cipher_list configuration like this
(Remove all the ciphers with "RSA" although I can't say
whether this is a good idea, especially if you need compatibiluty
with older clients.)
https://gist.github.com/keithws/d073c6f825e02fc823a7c32d406acadajustina colmena follows up with
I want better explanations of the maths.
If RSA and DSA algorithms based on standard arithmetic exponentiation modulo the product of two large primes are "deprecated" -- that means that there have been or are expected to be major mathematical and algorithmic advances in factoring large integers.
Disclaimer: I'm not an expert on this.
I don't think RSA is in any immenent danger of being broken, although there are some theoretetical factoring methods if quantum comoputing becomes a thing. There are other reasons to avoid RSA key echanges.
- EC keys are smaller and stronger for the same key size. Not a
hugely compelling reason as key exchanges are only a miniscule
part of overall processing.
- perfect forward secrecy: the disclosure of a private
key will not compromise past traffic. This is probably the
more compelling reason.The maths are easy for those algorithms, whereas the ECC algorithms are based on very advanced maths which aren't being explained satisfactorily to the general public,
To be fair, just because people understand what primes are and will just take a mathematician's word for it that factoring is hard, neither topics can be satisfactorily explained to a layperson so that their strength is apparent. There is an argument to be made (and people have made them) that EC is hard to do right, so curve parameters should be chosen to minimize the chance of implemenatation mistakes and side-channel leaks. Also, some NIST curves parameters were chosen in less than fully transparent way -- that's not to say they're broken, but it open them up for suspicion.
You can YouTube various terms and get tutorials at various levels of technical complexity, but the mathematics can get pretty hairy for both key exchange methods.
Joseph Tam jtam.home@gmail.com
On 13/01/2022 03:22 Joseph Tam jtam.home@gmail.com wrote:
dovecot@ptld.com writes:
Is Diffie-Hellman needed on a modern new dovecot setup?
Needed? Strictly speaking, probably not. Most clients will fall back to RSA, although some security hardened clients might refuse if you don't have non-RSA ciphers.
Dovecot default cipher list since 2.3 does not permit non-pfs ciphers. So ECDH(E)/DH is mandatory.
However i see Diffie-Hellman related warnings in logs: dovecot[1073]: imap-login: Error: Diffie-Hellman key exchange requested, but no DH parameters provided. Set ssl_dh=
Am i causing issues for some users by not setting up ssl_dh or is this something being phased out?
It just something you have to do to start using DH, analogous to having to generate 2 primes when using RSA. If you don't set it up, DH can't be used.
This means that an old client connected, and wanted to use non-EC based DH.
And follow up question;
The docs say you are encouraged to disable non-ECC DH algorithms completely. However i didn't see anything on that same page explaining how to go about doing that.
Can someone point me to something explaining what that means and how to go about doing it?
You have to specify your own ciphersuite via the ssl_cipher_list configuration like this
(Remove all the ciphers with "RSA" although I can't say whether this is a good idea, especially if you need compatibiluty with older clients.)
https://gist.github.com/keithws/d073c6f825e02fc823a7c32d406acada
This is also documented in
https://doc.dovecot.org/installation_guide/upgrading/from-2.2-to-2.3/#diffie...
ssl_cipher_list=ALL:!kRSA:!SRP:!kDHd:!DSS:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK:!RC4:!ADH:!LOW:!DH@STRENGTH
justina colmena follows up with
I want better explanations of the maths.
If RSA and DSA algorithms based on standard arithmetic exponentiation modulo the product of two large primes are "deprecated" -- that means that there have been or are expected to be major mathematical and algorithmic advances in factoring large integers.
Disclaimer: I'm not an expert on this.
I don't think RSA is in any immenent danger of being broken, although there are some theoretetical factoring methods if quantum comoputing becomes a thing. There are other reasons to avoid RSA key echanges.
EC keys are smaller and stronger for the same key size. Not a hugely compelling reason as key exchanges are only a miniscule part of overall processing.
perfect forward secrecy: the disclosure of a private key will not compromise past traffic. This is probably the more compelling reason.
The maths are easy for those algorithms, whereas the ECC algorithms are based on very advanced maths which aren't being explained satisfactorily to the general public,
To be fair, just because people understand what primes are and will just take a mathematician's word for it that factoring is hard, neither topics can be satisfactorily explained to a layperson so that their strength is apparent. There is an argument to be made (and people have made them) that EC is hard to do right, so curve parameters should be chosen to minimize the chance of implemenatation mistakes and side-channel leaks. Also, some NIST curves parameters were chosen in less than fully transparent way -- that's not to say they're broken, but it open them up for suspicion.
You can YouTube various terms and get tutorials at various levels of technical complexity, but the mathematics can get pretty hairy for both key exchange methods.
Joseph Tam jtam.home@gmail.com
RSA has nothing to do with this, in fact. Diffie-Hellman key exchange uses (see https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange) modulo based arithmetics to end up with same number on both sides.
ECDH does practically the same thing, using elliptic curves instead. The upside of ECDH is that it's a lot faster than traditional DH and provides comparable level of security.
You still use RSA with key exchange, unless you are using ECC keys with your certs. The key exchange part is done to make it impossible to decrypt previous sessions in case you have recorded the traffic and somehow become in posession of the server's private key.
Aki
On January 12, 2022 4:22:00 PM AKST, Joseph Tam jtam.home@gmail.com wrote:
- perfect forward secrecy: the disclosure of a private key will not compromise past traffic. This is probably the more compelling reason.
As to ECC vs. the "old fashioned" RSA paradigm based on the difficulty of factoring very large natural numbers --- that's a totally separate issue, irrelevant to that of choosing protocols that offer PFS over those that do not.
I'm "convinced" on no special considerations beyond elementary math that the product of two large randomly chosen primes numbers is darn near impossible to factor on modern computers. Scientists have tried and failed and assiduously documented their vain attempts at cracking the RSA challenge up to commonly used key size parameters.
The ECC business for involves too many secret codes and ciphers coming out of a college fraternity or university dormitory, and it's not clear to me as an outsider what it offers beyond smoke-and-mirrors obfuscation and security by obscurity of the algorithm. The magic numbers and specially chosen curve parameters like "25519" offered as is without explanation are alarming to me as if someone is trying to pull the wool over my eyes with the fancy maths.
Sent from my Android device with K-9 Mail. Please excuse my brevity.
On 10/01/2022 18:12 dovecot@ptld.com wrote:
And follow up question;
The docs say you are encouraged to disable non-ECC DH algorithms completely. However i didn't see anything on that same page explaining how to go about doing that.
Can someone point me to something explaining what that means and how to go about doing it?
Bit hidden in the documentation, but https://doc.dovecot.org/installation_guide/upgrading/from-2.2-to-2.3/#diffie...
participants (4)
-
Aki Tuomi
-
dovecot＠ptld.com
-
Joseph Tam
-
justina colmena ~biz