Ok Google: please publish your DKIM secret keys

It doesn't at all. You're misunderstanding. Or, are you using the word "literally" in the modern sense of "not literally"?

We've backed into a particular default, more via path-dependencies than conscious choice, that:

* emails between major email providers have this lingering semi-authenticity indicator that authors didn't explicitly choose

* to the extent the providers keep their DKIM keys non-public, only those providers (or those who exfiltrate such keys) can forge old emails

Both of these have problems if considered from 1st principles:

* Users should be able to control if they're creating non-repudiable messages.

* No one, not even Google, should have the power to create authentic-seeming forgeries.

This article's author, Matthew Green, suggests rapid expiration & disclosure of DKIM keys to narrow the window of time the user is subject to a non-repudiation they didn't choose. (Green here only specifically requests disclosure of years-old keys to invalidate older message archives, but conceivably a rigorous expiration-and-disclosure schedule could be chosen to limit the risk to weeks or days.)

And via public disclosure, Green intends to indirectly address the risk of privileged parties forging emails, by giving everyone the same power-to-forge older emails - so no particular forgery can be too convincing.

But these new defaults are nearly as ad-hoc – reactive without conscious design – as the DKIM problem they purport to solve.

Many would prefer that their emails, or at least some of them, be non-repudiable for a while or indefinitely. Many recipients would like to maintain their own private authenticity records – which as Green notes, can be bootstrapped into existence (even with rapid-expiring DKIM keys) by secure-timestamping messages & current DKIM keys at the time they're received.

(To the extent Google & other providers have internally-trusted tamper-proof logs, they may already have de facto secure timestamping happening on all inbound/outbound email. Thus any amount of DKIM key fouling wouldn't stop their unique internal ability to authenticate older messages, for their own forensic or political purposes.)

I'd prefer users be given some visibility into, and choice over, how much durable authentication is added to their email messages – before adopting either Green's quick fix (publish old keys ASAP), or defaulting all users to his potential longer-term solution of explicitly "non-attributable email" (per his KeyForge paper or other schemes).

> I'm struggling to find compelling and valid reasons why we can't pursue a general solution that involves us giving all this "private" data to a government entity for legitimate investigations, fraud prevention and crime-solving whilst keeping that data free from abuse.

Because that's not logically possible. It would be nice if it were, but just think about it: if you give data to the government, humans can look at it. Can we ensure that the humans who look at it are good humans? No. Is there some mathematical way of signing and encrypting such that only good humans can look at it? No.

Okay, so it's logically impossible to keep bad people out mathematically, but maybe it's a practical problem and it doesn't matter in practice? Except no, there are tons of evil governments (CCP being the most obvious, but pick your poison), and even good governments are subject to the problem that people can bribed and secrets can be stolen if there is sufficient motivation. It's just not compatible with human nature to say "collect all this information on people, but only use it For Good Purposes."

The piece seems to be arguing from a general principle. Repudiation is a feature of most secure messaging applications and it is a feature that should be introduced to GMail. This argument doesn't fully address how technologies are actually used today.

As far as I can tell, people who need repudiation are already using apps that have repudiation (eg Signal), because they know they are in a vulnerable position. The people who need repudiation already have it. So far we have seen DKIM authentication used against individuals in positions of power. With things as they are, cryptography is leveling the playing field by empowering the vulnerable while holding those in power responsible. If this situation or balance were to change perhaps it would make sense to rethink DKIM non-repudiation. I understand this is an opinionated/political take on cryptography that not everyone would share.

First: I don't think Matthew Green "resorted" to anything. I think he chose the blackmail example because it's easy to understand on a personal level: we all use repudiatable protocols in other contexts (like Signal), so why wouldn't we want it on our emails?

Second: That's not how blackmail works. It's contingent on what the extorted party thinks, not the cryptographic integrity of the blackmail material. That's why mass blackmail spam campaigns (that DKIM fails to prevent, ironically enough) are remarkably effective. Publishing DKIM secret keys after their expiry doesn't magically prevent blackmail; it just removes one more tool from the blackmailer's toolbelt for instilling fear in the target.