Is Diffie-Hellman needed?

[Aki Tuomi]

> On 13/01/2022 03:22 Joseph Tam <jtam.home at gmail.com> wrote:
> 
>  
> 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.
> 

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=</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.
> 

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-hellman-parameters-for-ssl

ssl_cipher_list=ALL:!kRSA:!SRP:!kDHd:!DSS:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK:!RC4:!ADH:!LOW:!DH at 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 at 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