[DKIM-SECURITY] Module is way, way too simplistic and has big flaws

Here are some features that would help:

  • Setting what headers will be signed (in addition to the body).

  • Being able to choose match-modes between strict and loose, the latter being ok with minor modifications from other MTA relays and such and is sometimes preferable.

  • It defaults to test mode, which is WRONG. It defeats the entire purpose of DKIM. The "t=y" flag should only be enabled if you want to be notified about errors (the spec says that domains with that flag are requesting deployment help and feedback), and it signals to the world "it doesn't matter if the signature doesn't match since we are still in the test phase".

  • The better mode is "t=s" which locks it down so that the key is strictly verified against the exact domain of the sender. You can't mismatch and send an email from @foo.bar.baz.com and sign it with a @bar.baz.com key in that mode.

  • [DNS issue] The DKIM key is not added when you create sub-servers UNLESS you tell those sub-servers to create their brand new, own DNS zone. The Key is added perfectly to all master/main servers, of course.

  • The previous point is serious, because cat /etc/mail/dkim-milter/keys/keylist shows it's enabled for the subdomains even though they lack the key record in their DNS, meaning that outgoing emails will fail validation since no key can be found. (The solution is of course to always create sub-domains as their own, new master DNS zone)

  • The "DNS records for additional domains" field lies. It says "k=rsa, t=y, p=" but the actual record that's inserted in domains is "v=DKIM1, k=rsa, r=postmaster, t=y, p=" - this needs fixing.

  • Moreover, it lists a DomainKey (deprecated) policy entry. We should not be using DomainKeys anymore, so the policy entry (the one with "o=-") should not be listed in the box.

  • The default key length is 2048 bits, but like I mentioned in another ticket this breaks BIND since Virtualmin doesn't write long DNS TXT entries properly.

  • The default key length of 2048 bits is bad. It's excessive. It's like 20x slower, for almost zero benefit. Security researchers have estimated that it would take a year of processing time on a $200 million dollar machine to brute force a 1024 bit key.

  • The fact that 2048 bit keys are 20x slower (or more) than 1024 bit keys mean that it puts lots of load on the sending and receiving servers. Instead of checking a key in milliseconds, it may take 200 milliseconds.

  • Keys should be rotated yearly anyway, so there is zero benefit to going over 1024 bit today. Just harm. Like the DNS length issue, and slowness.

  • The longer 2048 bit keys also slow down the DNS query since every client is forced to redo the request via TCP rather than UDP, becuase the UDP reply can't fit the whole key.

So, recap:

  • Do not create the deprecated _domainkey policy entry
  • Make sure the DKIM key is added to every domain even when they are children of parent zones, since messages are always signed (so key MUST be available in the zone)
  • Add an option for key size which defaults to 1024 bit and can optionally be set to 2048 bit with a warning that it's SLOW and harms the recipient systems of your messages.
  • Add a "test mode" toggle which switches between "t=y" (test) and "t=s" (lockdown, production use)
  • Tweak the DNS editing module so it supports > 255 character TXT entries properly

Anyway, here are my temporary patches to make DKIM better until official fixes:

# sed -i 's/t=y;/t=s;/' /usr/libexec/webmin/virtual-server/dkim.cgi
# sed -i 's/t=y;/t=s;/' /usr/libexec/webmin/virtual-server/dkim-lib.pl
# sed -i 's/my \$size = 2048;/my \$size = 1024;/' /usr/libexec/webmin/virtual-server/dkim-lib.pl
Closed (fixed)


I'll definitely fix that DKIM test mode flag in Virtualmin 3.99.

Regarding key size - 2048 seems like the safer option to me, since anything less than 1024 is already considered insecure. 1024 may seem OK now, but how about in a few years?

Also, a 200ms validation time doesn't seem like a problem at the rates email is typically sent.

"anything less than 1024 is already considered insecure"

Have you done any work in crypto?

A 512 bit key can be cracked with a botnet in a few months.

Here's the thing:

If I asked you how strong a 513 bit key is, the answer is actually: Twice as strong.

A 514 bit key is 4x as long as a 512 bit key.

A 515 bit key is 8x as long as a 512 bit key

A 516 bit key is 16x as long as a 512 bit key

A 517 bit key is 32x as long as a 512 bit key

A 518 bit key is 64x as long as a 512 bit key

A 519 bit key is 128x as long as a 512 bit key

A 520 bit key is 256x as long as a 512 bit key

A 521 bit key is 512x as long as a 512 bit key

A 522 bit key is 1024x as long as a 512 bit key

Now imagine going up to 1024.

Do you now see why 1024 bit is extremely secure?

It's not just "a little bit" better or "twice as good". The numbers are mindblowingly huge.

Most people use 1024 bit keys now. The only people that use 2048 bit keys are ones that either have no clue about how cryptography works, or understand crypto but wear tinfoil hats thinking they may be targeted by the government. They are the only ones with the computing power to even have the faintest chance of cracking a 1024 bit key.

So ask yourself: Are the majority of Virtualmin users targeted by worldwide governments? No? Then the only sane default is 1024 bit.

By the way, there are no governments that have access to machines that can crack 1024 bit keys. It's just not feasible with today's computers.

The next Virtualmin release will let you choose the DKIM key size, and will fix the other bugs you mentioned..

Automatically closed -- issue fixed for 2 weeks with no activity.