DKIM is very good technology. It does not give the same confidence as PGP or S/MIME but it does do a fairly good job at giving the confidence the message has not been altered since it was signed on an MTA authorized to sign for the mailbox domain, and the end user does not have to do anything technical like they do with PGP and S/MIME.
But there are some practices that should be cleaned up by system administrators and maybe could use some exposure.
A) A very large percentage of keys are RSA 1024-bit. System administrators need to be encouraged to use 2048-bit with RSA.
B) A very large percentage of keys are never replaced. This is particularly bad with 1024-bit keys. System administrators should be encouraged to generate new keys about once a year. Encouraging them to put the YYYY at the end of the DKIM selector they use when generating keypairs makes it easier for them to visually see when an old key is being used.
C) Large number of DKIM validators are not able to validate messages signed with Ed25519. Granted that is brand new and only recently added to the spec. But for server-side validation we should really encourage server admins to update their software so it can validate those messages, so that eventually it can be the recommended algorithm and RSA deprecated.
C is hard, OpenDKIM does support it but only in their development releases and it requires a very fresh version of OpenSSL to do so. But I imagine soon their stable release will support it, and hopefully sysadmins will run new enough OpenSSL (I think 1.1.1 is required)
@sydneyli has been engaging with the e-mail admin community via MAAAAAWG (I don’t remember how many As there are) and her work on STARTTLS Everywhere—maybe she has a perspective on the use of DKIM.
Personally, I suspect that a very large mail host like Gmail would be in a much stronger position to influence this (they’ve already influenced STARTTLS adoption quite a bit with security indicators on individual e-mail messages), as would e-mail server software developers and packagers.
I think I remember that someone involved with DKIM argued a few years ago that the short keys were OK in this context because the value of cracking one was relatively low and the keys could simply be changed periodically to reduce the impact of an attack. I don’t know whether this argument is particularly reasonable, but I suspect a lot of DKIM users are still relying on this reasoning.
Yes, the RFC itself says that weaker keys are okay because they can be changed frequently. The unfortunate reality is because they do not expire, they often go for years without being changed. Also, the weakest link is usually human psychology - allowing for social engineering. If a weak key is cracked, that makes it easier for the attacker to potentially socially engineer the victims because they can fraudulently sign e-mail messages that appear to be genuine. Assuming weak keys are okay because it isn’t “as important” is flawed especially when they are rarely regenerated.
To some extent Google is already influencing this - many Google apps allegedly require 2048-bit DKIM or they ignore it. However it seems they don’t really make a big deal out of it.
Which security indications are being generated based on DKIM validation? Are there any known cases where this kind of attack has happened so far? (presumably with 512-bit or 768-bit keys rather than 1024-bit keys)
Many mail clients indicate whether or not the message has a valid signature, and DMARC requires a valid signature. As far as known cases, no I can’t name one where it has happened but that isn’t the point. It would be very valuable to social engineering, for example, to sign a message from paypal.com and have it validate - where an invalid signature or no signature may (hopefully) results in the message going to junk if paypal.com is in the From header.