Docker Mailserver
How to approach DKIM key renewal (rotation)? Can an expiry be set? #4068
-
|
The docs clearly state how to set up DKIM, and generate the sertificate with the setup tool. However, I couldn't find what the proper procedure is to renew the certificate, and if I'm notified automatically when it is about to expire. Is there some documentation about this? Also, it is possible (maybe not wise but still) to set the lifetime of the DKIM certificate? (I didn't see an option for this in the |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 3 replies
-
I don't think we have documentation on that. DKIM keys are used to sign your mail so that the receiver can verify authenticity of the contents they're viewing. The public key needs to remain in DNS record for that verification years down the line, otherwise verification cannot occur. The value of DKIM signing is more to do with verification in the short-term, such as when accepting the mail. There isn't much value of a DKIM private key being compromised when the mail has already been sent as that contents cannot be altered and the mail was already accepted. Contrast to a TLS certificate, where you can impersonate a server identity, and if non-PFS cipher suite was used then decrypt any prior encrypted traffic (although it should be uncommon these days for non-PFS TLS connections). I can't recall exact details, but DKIM keys being compromised was less impactful than TLS keys. Might have been due to TLS having a handshake step where the private key is necessary during the connection being established, while I don't think DKIM verification needs any interaction with the mail server beyond getting the DNS public key record it needs? There is no notification support, but you could automate renewal or a notification to do so via a scheduled task (cron / systemd-timer) or reminder (for manual renewal)? I believe the term for DKIM is called "rotating keys". Since you may not want to replace the DNS record of the public key, you would keep that, and add a new public key record for another DKIM public key paired to the new DKIM key. Then future emails use that DKIM keypair to sign and verify. How often you rotate is up to you, I think I've seen 6 months to 2 years advised elsewhere online.
RSA 2048-bit should be fine to continue with. The reason I provide the above information is that it's context for your rotation policy. Ignoring any other breaches to obtain a your DKIM private key, if someone was to invest the resources to brute force a solution, you can raise that symmetric security difficulty higher to offset the rotation time. If my math is accurate though, and you take into consideration that you're probably not a target an attacker could justify spending that sort of money on to acquire your DKIM key to sign mail with, there's not much value in verification of existing mail that was already signed AFAIK? The attacker would benefit investing the resources on more valuable assets, but for the cost it'd be more affordable to get private keys for TLS and DKIM via other means. Thus you should be fine with RSA 2048-bit, and your rotation window is what an attacker could leverage if they acquire your DKIM key via other means. Which is access to your systems involved in generation/transfer and storage of the DKIM private key. If they have that, they can quite possibly continue to access it when you rotate keys. At this point it's beyond my expertise to advise as I'm not a cyber-security specialist 😅
As we covered above, I don't think there is such a concept. A TLS certificate (or rather X.509) provides all that extra information, whereas with DKIM we just have a private and public key, there is no other data associated to it as it only serves to provide trust via verification IIRC vs trust via authentication that TLS offers (handshake to server + third-party root CA verification).. It's been a while since I deep dived this topic, so I might be a little rusty with details, but that should be the gist of it. I have a TODO task to simplify the DKIM generation so that it's more agnostic (OpenDKIM + Rspamd compatible), and more transparent with the keypair generation. You can refer to that if it helps provide more insight. You'll see there is no expiry date involved in the generation, nor does the tool ( |
Beta Was this translation helpful? Give feedback.
-
|
Thanks a lot for you thorough answer polarathene! My main concern wat that all of a sudden email would no longer be accepted because of some expired DKIM keys. But as I understand from your reply, these keys basically are valid indefinately. So that could never happen. So basically, for a simple home server like mine, there would normally be no good reason to replace those DKIM keys. Maybe it's worth to add a little note to the DKIM page, indicating that the DKIM key do not expire, so basically need no maintenance once set? Thank you very much for your time and valuable answer! It's really appreciated! |
Beta Was this translation helpful? Give feedback.
-
|
Apparently the DKIM key can have an expiry set, but it's part of the DKIM signature per mail sent: https://mxtoolbox.com/problem/dkim/dkim-signature-expiration The metadata is to state when a DKIM key should be considered invalid, which AFAIK equates to an expiry for verification itself rather, even when the DKIM public key would otherwise be valid. So rotating/renewing your DKIM keypair won't prevent verification failure in that scenario (not that it should be relevant by that point). There's also an attack called "DKIM replay attack" where including an expiry in the signature should help minimize that, but AFAIK that doesn't require rotating the key itself.
I'm not a security expert, but AFAIK you should be fine. I've not checked, but if the mails signed by your DKIM key do include an expiry, then you probably can just rotate a DKIM key without introducing a new selector - but it'd probably be wiser to alternate between two DKIM selector records to properly phase out a key from the last mails expiry (assuming it's always a relative offset duration from when sent, rather than a fixed timestamp).
Sounds good 👍 PR ready: #4076 |
Beta Was this translation helpful? Give feedback.
-
|
According to a report by Quintessence Labs titled Breaking RSA Encryption – an Update on the State-of-the-Art, “It would take a classical computer around 300 trillion years to break a RSA-2048 bit encryption key.” So using a strong, 2048-bit key dramatically mitigates this risk. I would never rotate my keys. What's your point in rotating keys? and do yo know what sets the DKIM selector in in the DKIM-signature in the first place? |
Beta Was this translation helpful? Give feedback.
-
My answer highlights the difficulty in a different way, we ignore compute capability entirely, you could have all the processing power in the world and regardless of time the amount of energy required is enough to boil all the oceans in the world... so I think such an attack isn't particularly accessible or subtle to carry out 😅 Even with quantum compute, where it's claimed that attacking an RSA key is much faster, this conveniently disregards other resources involved, and AFAIK isn't that more efficient/affordable (IIRC, there's some jargon on logical qubits to keep in mind since some systems claim higher qubit capability but that was for something like error correction, so actual meaningful qubits was much lower). I believe when I looked into it, scaling up to RSA 2048-bit just wasn't anymore practical than the cost and feasibility to attack with traditional compute.
Again my answer should clarify that there isn't much value from a brute-force attack. However there are other scenarios to account for, such as an attacker gaining access in some manner to your DKIM private key, where rotation may have some value in minimizing the damage that can be done (similar to how TLS certs are rotated, despite being quite strong, but for verification on delivery only, the value of attacking DKIM is lower). For a small mail server, especially a private one just for you... I doubt there's much risk to protect against. All you need to do is avoid low-effort / cheap attacks, so long as nobody is specifically targeting you (and has the resources to do so), rotating keys is probably redundant security. A better example may be in a safe neighbourhood, people may not lock the doors to their homes (and the value of goods may also be lackluster to an interested party), while a bank or other building with notably more value held would very likely still secure itself as it's far more likely to be targeted by a thief otherwise as opposed to a random home. Google used RSA 512-bit DKIM keys at one point (while serving stronger TLS certs) and someone took advantage of that to impersonate their CEO. That's far less practical with a RSA 2048-bit DKIM key, but given Google is a more desirable target an extra precaution for them would be to rotate keys. Rotation would also allow for reducing the key size if that was meaningful (less bandwidth use and CPU time), but at the scale of most (all?) DMS deployments that's unlikely? 😅
When mail arrives on port 25, if that mail has a DKIM signature it should be verified before it's accepted by DMS (Postfix). When mail is submitted (ports 587 / 465), then the DKIM signature should applied by either the current default OpenDKIM service (via integration with Postfix), or our alternative opt-in (and future default) Rspamd. The DKIM selector to sign with is determined by the OpenDKIM or Rspamd equivalent configuration file. When you use our Rspamd I think can be a bit a more flexible in DKIM selector mapping, but generally you have a key per domain, or you can have a single key for multiple domains (and each domain would have the equivalent DKIM public key in their DNS records). |
Beta Was this translation helpful? Give feedback.
I don't think we have documentation on that.
DKIM keys are used to sign your mail so that the receiver can verify authenticity of the contents they're viewing. The public key needs to remain in DNS record for that verification years down the line, otherwise verification cannot occur.
The value of DKIM signing is more to do with verification in the short-term, such as when accepting the mail. There isn't much value of a DKIM private key being compromised when the mail has already been sent as that contents ca…