Yes, that's the point though: To make DKIM not serve as a non-repudiation mechanism. It forces actors to go through other notarization steps instead of relying on DKIM.

> Yes, that's the point though: To make DKIM not serve as a non-repudiation mechanism.

The devil is right in the details... it is serving just as perfectly fine as a non-repudiation mechanism as it ever was, just constrained in time to a day or so as suggested by the article. Depending on what you said to whom that you wish you hadn't said, that can be all you need to get into trouble.

Are you familiar with the concept of Post-Compromise Security?

There is no compromise and no security breached. Just a guy who really did say something and wishes there was no evidence he said it.

Publishing the privkey just makes it so in other circumstances where he might strongly wish that he had evidence he HAD said something, the dkim signature is devalued.

The author is nonbinary, not male.

Yes. In the specific example that I gave though (the recipient being your friend), it likely wouldn't happen because your friend is not going to get something notarized to use against you. There could still be a problem if the hacker has control of your friend's email account while you send your email, because then the attacker can get it notarized.

I'm not a he, but you're correct that a counterparty can easily break delayed key disclosure as a way to have plausible deniability. This was brought up in the Twitter thread (though reading a conversation on Twitter that has any forks is... a chore) started by Matthew Green.

Thinking about this more, maybe an alternate technique to provide plausible deniability is to setup a service that acts as a signing oracle with your private key. To avoid it being used for impersonation you might be able to implement a system that receives signing requests via email, and will only sign emails that have the "to" address equal the source of where the signing request came from.

Attack: Sign up for email accounts at major providers, use the signing oracle to sign spam emails, submit to provider, domain's reputation becomes spammy.

The handling rules standardized by DMARC are to ignore failing SPF when there is a valid DKIM signature, even if the domain doesn't use DMARC. Google, in particular, ignored SPF failures on DKIM signed messages last I checked.

Interesting. What if you required payment, say via Monero, for each signature? That would slow down the creation of spam emails.

If you're a low volume email sender, anything attributed to your domain getting marked as spam can cause serious pain. It's an interesting idea, but not an experiment I care to run.