>Is the author just building plausible deniability by publishing the keys?

Yes.

>Would this even truly stand up as believable for any scenario?

The post says this will most likely only work in a leak situation rather than a legal dispute. An example of where this might be useful: You send an email to a friend revealing something sensitive about yourself. A hacker hacks your friend's email and leaks it out. Without plausible deniability, everyone can verify cryptographically that you did in fact say that sensitive stuff (assuming your own email didn't get hacked). With this technique, people cannot verify whether or not you said it, the email might be a fraud and so people are less likely to believe the sensitive thing about you.

> With this technique, people cannot verify whether or not you said it, the email might be a fraud and so people are less likely to believe the sensitive thing about you.

If the recipient can prove he had the signed email before the signing private key was made public, eg, by contemporary third party notarization, the keys becoming public later don't help with disclaiming it at all.

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.

As long as no one archives your DKIM public keys which are available to anyone who asks.

Why would people archiving your DKIM public keys be a problem?

Sorry I think I misunderstood your post. You are right.