Tuesday Tip: DKIM Oversigning, enable it if you can
URL Copied
For last week's Tuesday Tip, I shared my top five recommendations for DKIM best practices. Mostly (hopefully) easy things you can implement in your DKIM consideration, or nudge your email marketing automation platform to take care of, depending on whether or not you're able to control your own servers and their configurations.
Today I'll add tip number six: Consider enabling oversigning in your DKIM configuration.
What is DKIM oversigning?
When configuring DKIM, you're typically able to specify which headers should be covered by an email message's DKIM signature. This means that, in addition to the message body, if those headers are modified after the message was initially generated and signed, if any bit of any of those things covered by the signature is modified after creation, any further attempt to verify the DKIM signature will fail.
If a bad guy takes your email message, modifies it, and re-injects it into the mail stream, whatever destination server it's aimed at will perform the usual set of authentication checks against this inbound email message. SPF will fail, as usually the bad guy is re-injecting this message from a server different from where it originally originated. And DKIM will fail, because content has been modified to the point that the DKIM signature's hash will no longer verify when checked. With neither SPF or DKIM passing successfully, it's DMARC failure time and your DMARC policy can prevent this message from ever being delivered on to whomever the bad guy is trying to annoy with it, preventing reputational damage from being leveled at your email domain name.
The DKIM protection here applies only to the specific bits of an email message as configured in the sending system. As I mentioned, that starts with the message body, and then typically encompasses a set of headers as well. You can see which, just by looking at the email headers of a delivered email message. Right there in the DKIM-Signature header, the "h=" field contains the headers that are covered by the DKIM signature.
How to implement DKIM oversigning
If you're using an MTA platform that supports oversigning, reference their documentation and implement it.
Oh, and ironically, I can't get it to work in my own environment of Postfix + OpenDKIM. I'll keep hacking at that but ran out of time and tries before publishing this article.
When configuring oversigning, you're often able to specify which headers you'd like to include, leading to the question: Which headers should you oversign? The common recommendation starts with Date, Subject, From, To, and CC, but if you review RFC 5322 to see what headers are supposed to appear no more than once in an email message, that expands to To, Cc, Subject, Date, From, Sender, Reply-To, Bcc, Message-ID, In-Reply-To, and Reference.
My take there is that it can't hurt to oversign any header that should only appear no more than one time in a message. If you disagree, let me know why in comments, and I'll include mention of that here.
Why do DKIM oversigning?
To make it harder for bad guys to usefully implement a DKIM replay attack while adding their own content. Disallowing specific additional headers to be added reduces the ability for bad guys to add in headers that might show through to the new recipient(s). No way to add content means no way for a spammer to invite a spam recipient to click on their spam website link.
Do I really have to do DKIM oversigning? What if I can't?
Even if you don't implement DKIM oversigning, some mailbox providers have implemented their own controls to mitigate the risk from DKIM replay by catching rogue header additions and through various other means. Google, for example, back in 2023 began to reject messages that contained more than one of any header that should appear no more than once. You can read more about that here. (It is widely believed that Google also has other means of preventing some times of DKIM replay attacks, as well.)
In Conclusion
In the spirit of condensing a long story down to a short final paragraph, I guess it boils down to this: DKIM oversigning is something that, if easy to do, do it, because Gmail isn't the only mailbox provider out there and you ought to make it as hard as possible for bad guys to re-inject your content into the email stream. In that way, I would very much consider it a best practice.
Alternatively, lack of support for DKIM oversigning is perhaps not a reason to jump ship on your current MTA or marketing automation platform. Certain mailbox providers are mitigating the multi-header DKIM replay risk on their own, whether or not you're able to modify your send configuration.
How's that for a mixed message? Sometimes it gets a little messy when you start to dig into things; and this post, which started out intending to be a simple Tuesday tip, has already gotten way too long. So we'll just leave it there for today, and thanks for reading!
For last week's Tuesday Tip, I shared my top five recommendations for DKIM best practices. Mostly (hopefully) easy things you can implement in your DKIM consideration, or nudge your email marketing automation platform to take care of, depending on whether or not you're able to control your own servers and their configurations.
Today I'll add tip number six: Consider enabling oversigning in your DKIM configuration.
What is DKIM oversigning?
When configuring DKIM, you're typically able to specify which headers should be covered by an email message's DKIM signature. This means that, in addition to the message body, if those headers are modified after the message was initially generated and signed, if any bit of any of those things covered by the signature is modified after creation, any further attempt to verify the DKIM signature will fail.
If a bad guy takes your email message, modifies it, and re-injects it into the mail stream, whatever destination server it's aimed at will perform the usual set of authentication checks against this inbound email message. SPF will fail, as usually the bad guy is re-injecting this message from a server different from where it originally originated. And DKIM will fail, because content has been modified to the point that the DKIM signature's hash will no longer verify when checked. With neither SPF or DKIM passing successfully, it's DMARC failure time and your DMARC policy can prevent this message from ever being delivered on to whomever the bad guy is trying to annoy with it, preventing reputational damage from being leveled at your email domain name.
The DKIM protection here applies only to the specific bits of an email message as configured in the sending system. As I mentioned, that starts with the message body, and then typically encompasses a set of headers as well. You can see which, just by looking at the email headers of a delivered email message. Right there in the DKIM-Signature header, the "h=" field contains the headers that are covered by the DKIM signature.
How to implement DKIM oversigning
If you're using an MTA platform that supports oversigning, reference their documentation and implement it.
Oh, and ironically, I can't get it to work in my own environment of Postfix + OpenDKIM. I'll keep hacking at that but ran out of time and tries before publishing this article.
When configuring oversigning, you're often able to specify which headers you'd like to include, leading to the question: Which headers should you oversign? The common recommendation starts with Date, Subject, From, To, and CC, but if you review RFC 5322 to see what headers are supposed to appear no more than once in an email message, that expands to To, Cc, Subject, Date, From, Sender, Reply-To, Bcc, Message-ID, In-Reply-To, and Reference.
My take there is that it can't hurt to oversign any header that should only appear no more than one time in a message. If you disagree, let me know why in comments, and I'll include mention of that here.
Why do DKIM oversigning?
To make it harder for bad guys to usefully implement a DKIM replay attack while adding their own content. Disallowing specific additional headers to be added reduces the ability for bad guys to add in headers that might show through to the new recipient(s). No way to add content means no way for a spammer to invite a spam recipient to click on their spam website link.
Here's more on DKIM replay attacks from Halon. I've also blogged about them here, and I previously presented a webinar alongside folks from Halon and the Certified Senders Alliance on this topic, too.
Do I really have to do DKIM oversigning? What if I can't?
Even if you don't implement DKIM oversigning, some mailbox providers have implemented their own controls to mitigate the risk from DKIM replay by catching rogue header additions and through various other means. Google, for example, back in 2023 began to reject messages that contained more than one of any header that should appear no more than once. You can read more about that here. (It is widely believed that Google also has other means of preventing some times of DKIM replay attacks, as well.)
In Conclusion
In the spirit of condensing a long story down to a short final paragraph, I guess it boils down to this: DKIM oversigning is something that, if easy to do, do it, because Gmail isn't the only mailbox provider out there and you ought to make it as hard as possible for bad guys to re-inject your content into the email stream. In that way, I would very much consider it a best practice.
Alternatively, lack of support for DKIM oversigning is perhaps not a reason to jump ship on your current MTA or marketing automation platform. Certain mailbox providers are mitigating the multi-header DKIM replay risk on their own, whether or not you're able to modify your send configuration.
How's that for a mixed message? Sometimes it gets a little messy when you start to dig into things; and this post, which started out intending to be a simple Tuesday tip, has already gotten way too long. So we'll just leave it there for today, and thanks for reading!
Comments
Post a Comment
Comments policy: Al is always right. Kidding, mostly. Be polite, please and thank you.