Lack of interest DKIM: Add an option to regenerate/update keys

[Kirby]

As per current recommendation, DKIM keys should be changed at least every 6 months.

Unfortunately, this is not really possible with the current implementation - the only option woulde be to disable DIKM and re-enable it afterwards.

My suggestion is to add a button "Regenerate Key" (ro smth. like this) what does the following:

1. Generate a new key pair, do not replace the private key immediately but store it for later replacement
2. Display instruction to add the new RR
3. Schedule a job to verify the the new DSN entry is active
4. Once it is active replace the current key with the new private key created in step 1

This would at least allow admins to manually update keys (and probably allow Add-ons to plug-in automation via the variuos DNS APIs out there).

 

[digitalpoint]

MAAWG isn't authoritative on the matter, rather just a "group" that gives recommendations based on who knows what. If you look at the document, it's based on the assumption that your server has been compromised and your private keys have been stolen. If your private keys are stolen, change them immediately (don't wait 6 months). They should also give the recommendation that you should tighten your security on your server so your keys don't get stolen in the first place.

While longer keys are harder to crack, the private (a.k.a. “signing”) key is still vulnerable to being stolen if an
attacker is able to compromise the system in which it is stored. Minimizing the amount of time a key pair is
in use ensures that, even if the key is compromised, the damage can be contained to a reasonably short
period of time.

If you are going to assume your private keys are stolen because your servers were breached, shouldn't you also assume your user database/passwords were all stolen too and force all users to change their passwords every 6 months (DKIM signing key is the least of your concerns if someone compromises the system and steals your things)?

Rotating keys doesn't fix the problem that your system was (or can be) compromised. Treat the problem, not the symptom imo.

 

[Kirby]

I don't disagree that MAAWG is "just a group", but looking at their members I'd say it isn't just an ordinary group - basically every important player in the industry is a member.

Sure, rotating DKIM keys every 6 months doesn't fix anything - nor does updating Let's Encrypt TLS certificates (at least) every 90 days.

Yet it is common practice and doesn't hurt (if it's automated).

 

[digitalpoint]

Not something I would do, but there's a lot of things in the world I wouldn't do. For people that want to, one thing to keep in mind is that you shouldn't just change your DKIM keys cold turkey because changing the DNS entry will invalidate older emails that have already been sent. So ideally you would want to have a unique selector (that is unique to the time you last changed it, not just xenforo). As an example, I just pulled the last email I got from Google (came on April 5)... their selector is simply 20210112 (I assume the date that DKIM key was put into use).

See that particular DKIM selector here: https://dmarcian.com/dkim-inspector/?domain=google.com&selector=20210112

...that way you can leave your old selectors and keep old email signatures valid.

To do it "right", you would need a lot more than XenForo is probably willing to do (for example automatic DNS record updates, which would be a whole other ball of wax to tackle with everyone using different providers).

Coincidentally, if that is indeed a date, Google (who is one of the highest-tier members of M3AAWG aren't taking their own advice about rotating their DKIM keys (been 15 months now).

Side note...

I looked up a few DKIM selectors from "major companies" I've received in the last month:

Sony: 200608
Cloudflare: scph0721
Amazon: eaxkvsyelrnxjh4cicqyjjmtjpetuwjx
USPS: no DKIM record at all because the government is retarded.
FedEx: 200608

Why is FedEx's selector the same as Sony (different servers)? lol Did someone write up a DKIM "how to" that they both followed word for word without understanding it? hah Googling it shows Best Buy used the same setup example, because theirs is 200608 (in 2009 it was anyway): https://www.mail-archive.com/dkim-milter-discuss@lists.sourceforge.net/msg01652.html

Boy did I get sidetracked...

 

[Kirby]

So ideally you would want to have a unique selector (that is unique to the time you last changed it, not just xenforo).
[...]
That way you can leave your old selectors and keep old email signatures valid.

Yeah, that is exactly what I suggested (assuming the constant is changed to a unique selector as pointed out in the related bug report)

To do it "right", you would need a lot more than XenForo is probably willing to do (for example automatic DNS record updates, which would be a whole other ball of wax to tackle with everyone using different providers).

I certainly wouldn't expect XenForo to implement full automation.
Using unique selectors each time DKIM does get activated (or key is regenerated) and only use keys after the corresponding RRs are available would most likely be fully sufficient to easily allow 3rd party Add-ons to deal with specific DNS APIs.