I can imagine why the author could maybe want plausible deniability against potentially leaked or forged emails, but I definitely see DKIM and non-repudiation a feature. I suppose the caveat is that if DKIM private keys were stolen, fraudulent emails could be convincingly generated, but this isn't a normal concern for users of the big hosted webmail services.
In the default setting, where it's not explicitly part of the security model, non-repudiation can be a vulnerability. A message is exchanged between counterparties, who verify its authenticity; they now know what they need to know. Allowing unrelated parties to reliably verify the message is conceding information to them. This is, for example, the reason that OTR deliberately leaks secrets after they're used.
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.
I'm not sure how common it is, but my mail server in particular doesn't store the signed emails, and I went to no special effort to set things up that way.
Of course, if someone replies to me and quotes my email to them, that will be signed by their server's key.
My reply was more to what tptacek said - observing that for at least some configurations a stolen mail spool from a laptop won't have signatures on sent emails.
One valid use case of non-repudiation that I can think of is the Poor Man's Copyright[0], where you email yourself your creative and have a timestamped record of when it existing.
What if you send the email from a reputable managed email service? That way, they're responsible for managing the keys, and can probably be trusted not to sign anything fraudulently.
Cheaper than paying for a digital signing service, but I imagine it wouldn't hold up as well in court.
Poor man's copyright is unfortunately quite tenuous and usually unenforceable.
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.
Yes, but that doesn't mean it can't be unenforceable. It simply means it hasn't passed the test of a court. However, isn't the same, from my limited research and knowledge, true for blockchain-based notarization?
DKIM does not offer cryptographic proof-of-existence or proof-of-time, which a blockchain does. That's the only functional difference, but crucial for copyright law.
Eh, fair question. Assembl is a pretty sought after name which we have the trademark on. I came up with the name after thinking it was necessary to "assemble" teams of scientists for collaborative research. I liked the name "Assembl" as it's the root for "assemble", "assembling", "assembly", etc.
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.
For context, this idea of publishing the secrets has come up again recently after DKIM was used to prove the authenticity of the “smoking gun” Hunter Biden email. [1]
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.
just for the record, while I mostly agree with the analysis on that page, I believe the author tries to make a stronger case than it really is.
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, v.pozharskyi.ukraine@gmail.com" - 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 hbiden@rosemontseneca.com" - 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).
DMARC does a decent job of solving a few of those points. Alas, that only proves the point that another commenter made about server-to-server SMTP being a hack-job piled on top of another hack job.
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.
Purely from an engineering perspective, in a setting where we care about privacy --- ostensibly, email is one of the settings where we care most about privacy --- the ability of a stranger to authenticate any particular historical email is a fairly grave vulnerability. Privacy-preserving systems go out of their way not to have it.
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.
