It's easy to see an example scenario: someone steals your laptop, then posts your mail spool publicly. You'd like to be able to say "you can't trust any of these messages", to mitigate the damage.
What I think confuses people is the fact that there are settings where non-repudiation is crucial to the security model. We're used to abstract cryptographic promises that apply universally to all systems. But this one doesn't.
I wonder how well the non-repudiation would actually hold up in that scenario. If you self host your mail server, the attacker could possibly steal your private key and forge the emails. So you might actually have repudiation. Or does DKIM have a timestamp? If not the attacker can simply send an email from your laptop and get it signed by your mailserver. Thus another route for claiming repudiation.
Of course, if someone replies to me and quotes my email to them, that will be signed by their server's key.
The signature can confirm parts of the email were not edited after it was signed, not that any of the contents were ever true or correct.
Cheaper than paying for a digital signing service, but I imagine it wouldn't hold up as well in court.
At my start-up we've built an analogous system which instead uses a public blockchain for notarization (as dirty as that word has become). https://assembl.net or https://app.assembl.net if you'd like to try timestamping right away.
Non-repudiation here is useful, but the timestamping is the more important piece.
* This is an assumption
§ I understand that you may be embedding Merkle roots to keep costs low.
> there is an absence of cases actually giving any value to the poor man's copyright.
Poor man's copyright without cryptographic proof or an immutable time boundary is pretty much worthless.
Edit: I would really appreciate it if the downvoters would at least attempt to have a discussion. The dogpiling tactic seems to be rather thoughtless.
- https://assembl.org and
are both infringers, but we haven't decided to go after them. The owner of https://assembl.com cannot be compelled to sell it, but can't sell it to anyone but us. For now, the focus is mainly on providing value to our userbase, as we grow these challenges are surmountable.
More generally, non-repudiation is a great feature if that’s what you’re going for. Often times it’s not actually what you needed at the time, but gets thrown in anyway because it’s harder to design a signing protocol without that property than with it.
So in the sense that non-repudiation isn’t a core requirement of DKIM you’d like to have the crypto algorithm which meets just the DKIM requirement and no more — yes, this email definitely came from an authorized server and hasn’t been tampered with, but without inherently proving that the email is not a forgery years later.
On the other hand, DKIM having this property is actually extremely useful and nice to have a lot of the time, not the least of which in the Hunter Biden case, or for the purpose of authenticating any particular historical email.
1) DKIM verifies the To: header, not the "rcpt to" receipient. The To: header has no value in determining who actually received the email. (Ex: you receive the email via BCC, you can't verify that the recipients listed in the To: actually got the email).
2) GMail actually does let users "spoof" the From: line. it needs cooperation from the "owner" of the address you want to use in the From line, but it is possible, and once set once, is never reconfirmed.
so, as I said, while I generally agree with the analysis, but I think 2 statements it makes are a bit too strong
1) "it was sent from this specific account, [email protected]" - It could have been sent via a different account that got the specific account's permission (either via a hack of sorts or cooperation) to spoof it. I'd agree that this isn't that likely.
2) "the intended recipient was to the account [email protected]" - all we can know is that this was the To: line, it is very easy to spoof this. (every email one gets via BCC is essentially spoofing this).
do I think either points are very likely? Not so much, but any page trying to prove the authenticity needs to address the limits of the analysis, which the author didn't do.
Of course there are other assumptions we make, notably that no one was able to steal or crack Google's old DKIM key. I wonder how many google employees would have had access to this DKIM key over time (and if security procedures might have been relaxed once it was "expired" and the public portion no longer distributed).
The one thing DKIM is good at is for protecting the From-header and body from modification, allowing receiving servers to verify that the sender is genuine whenever they receive an incoming message (when combined with DMARC that is). For anything else, use PGP, S/MIME, or something else that actually does end-to-end encryption/signing.
You may have some kind of public policy or archaeological argument in favor of the vulnerability, but then it's hard to see how the same argument doesn't suggest we should compromise the entire confidentiality of every email; after all, that would make research a lot easier.