[proto_lambda]

> It is trivial for a prosecutor to prove the owner of the domain, or the owner of the host that used the DKIM key

The point of publishing the keys is that _anyone_ can then sign messages, making "ownership of the domain" a meaningless factor, no matter how much you can prove it.

[djbusby]

Sounds like spammer could use the key then too? Send DKIM signed message from my domain?

[proto_lambda]

By the time you publish the key, it is no longer in your DNS records and thus no longer trusted by any receiving mail server.

[LeonM]

There lies the problem IMO.

The publication date of the DKIM record will be _after_ the email has been sent.

Obviously there is no real way to 'prove' the publication date of a DNS record, other than asking the DNS service provider for the logs maybe.

So IANAL, but I'd say the lack of provability of the publication date of the key makes it unsuitable for deniability. Just because the DKIM public key is currently public, does not prove in any way that it was already public when the email was sent.

[A1kmm]

Deniability means an adversary can't prove you did X, not that you can prove you didn't do X.

So to check if the property holds, the question is not: can you prove the key was public when the email was sent, it is a) can the adversary prove when the email was sent, and b) can the adversary prove that the key was not public at that timestamp?

On a), the adversary cannot just rely on Date: headers if those headers are signed by a public key, and the private key is now public - someone faking an email could just back-date the Date header to a date when the private key was not available, and hence an argument by the adversary that 'the Date header says it was sent at timestamp TS1, and at TS1, the key wasn't public, so therefore the email can't be repudiated' is not sound.

If the recipient of the email cooperates (or anyone who gets access to the email before the private key is published), they could, for example, hash all their emails, and then hash the list of hashes on a regular basis, and put that hash in a busy public blockchain. That would provide an upper bound on the email send timestamp, and, combined with a well-defined private key publication timeframe, provide non-repudiation.

[nulbyte]

> The publication date of the DKIM record will be _after_ the email has been sent.

Was that email even sent? Maybe it was forged after the key was leaked. This is what the author of the article is pointing out: The old private key being public, you can no longer rely on DKIM alone to prove anything about a document with a signature created with that key.

[maxerickson]

The point isn't establishing deniability, the point is undermining the authenticity argument (these are at least subtly different I think).

It isn't actually possible to prove that the key was secure at some point in time prior to publication, publication of the key moots that discussion, which is probably going to generally be socially favorable enough of the time to be the better thing to do.