Every DKIM signature needs an expiration date

Problem reported by Douglas Foster - Today at 5:59 AM

Submitted

Every newly-created DKIM signature should have an expiration date. The actual value should be an administrator choice. When evaluating DKIM signatures, an implicit expiration date should be applied to messages that lack one or messages that have an expiration date in the distant future. The need for this comes from an attack category called "DKIM Replay".

The attack starts with a compromised account, because the From address needs to one with a good reputation. Assume the compromised account is "victim@example.com". The spammer uses that account to send a malicious message to an account that he owns, such as "badactor@badguys.com". The malicious content is accepted, and it now has a valid DKIM signature for example.com.

Example.com quickly discovers the problem, takes back control of the account, and thinks they have dodged a bullet because their network was unharmed. No such luck.

The attacker replicates the unmodified malicious message to thousands or millions of desired victims. The message appears authentic because it has a valid signature from Example.com. If the signature never expires, the attack can go on forever. The poor system manager at Example.com will be mystified why his domain keeps showing up on the SpamHaus domain block list.

If the signature has an expiration date, at least there is an upper bound to how long the attacks can persist.

For the same reason, a message date or DKIM signature date that is not recent should be considered suspect and sent to quarantine. There is no perfect answer to the question of "How old is too old?", so both inbound and outbound expiration rules should be configurable by the system manager. I am thinking never more than 5 days.

Feature request ticket has also been opened.

3 Replies

Reply to Thread

Sébastien Riccio Replied

Today at 6:04 AM

For sure, DKIM key rotation est highly encouraged.

However its not that trivial, especially when you manage thousands of domains, as you must publish the new DKIM public key in the domain's DNS.

SmarterMail is already ready for DKIM key rollover, but you would probably need a script to handle this automatically through the SM API in conjunction with whatever DNS server you use's API.

And that's for the best case, I mean, when you have control on the domain DNS entries.

Sébastien Riccio System & Network Admin https://swisscenter.com

Sébastien Riccio Replied

Today at 6:07 AM

OK I misread, you're talking about the signature expiration itself, not the keys :)

Sébastien Riccio System & Network Admin https://swisscenter.com

Richard Laliberte Replied

Today at 8:04 AM

With Keys in mind, it would be nice is SM could do something similar to say Certify the Web, where we can plug in an API key for our DNS host, and it automatically regenerates keys say once a year, with a manual renew option?

Back to Community Threads

Please leave this box unchecked

Reply to Thread

Enter the verification text