dovecot at 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=</path/to/dh.pem
>
> 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/d073c6f825e02fc823a7c32d406acada
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 at gmail.com>