Description
All DKIM-verifying software support DKIM RSA keys. Only some (not that many)
support ed25519 keys. We currently create both keys for new domains, and sign
outgoing messages for that domain with both keys.
If a remote server does not support an algorithm, it has to (and does in
practice) ignore that signature, and uses other signatures with algorithms
that it does support. However, some of those servers then send DMARC reports
that mention a failing DKIM verification. And unfortunately, often with bad
diagnostics and/or few details. E.g. missing selector. The same applies to
the Authentication-Results headers that they create, which sometimes mention
"0-bit" keys. This confuses postmasters, causing them to investigate. It
takes time and is a chore. We can probably prevent this by only using RSA
keys.
I originally added both on the assumption that there would/should be a
move from RSA keys to ed25519 keys for DKIM. But that is probably not
happening:
- Because of all the mail servers with RSA-only support out there, we will
need RSA for a long time to come. RSA isn't broken, it works just fine
(well, except that the long public keys are annoying, they result in long
DNS TXT records, with multiple 255-byte strings, that some DNS provider
interfaces botch; but at least we check for in the self-check; ed25519 DKIM
DNS TXT records don't have this problem). - I think RSA verification is cheaper (in cpu cycles) than RSA signing, while
it's the other way around for ed25519. The RSA-case seems more attractive
for postmasters. Not sure if this makes an actual difference. - An added benefit is that users have to create fewer DNS records when
setting up a domain.