No. DKIM is meant to apply to emails in transit; it is part of the transaction of exchanging emails. But DKIM signatures are verifiable long after that transaction has completed. That was not an intended feature of DKIM, and it's a grave privacy violation.
To satisfy DKIM's design goal, you only need a "current" DKIM key that is secure for a window of time. When that window of time passes, you rotate the secret and publish your own key, repairing (hopefully) much of the privacy injury.
I'm missing something here. DKIM mostly proves an email from [email protected] was sent by a server @from.me controls. There is also a bloody great audit trail inside of the email with together with SPF can do a pretty good job of proving the same thing.
I'm struggling to see how an email sent to me, that presumably was always intended to be readable by me could suddenly become a privacy violation because it's signed. That is doubly so if I won't receive it if it isn't validly signed when it is received, which is often the case.
I'm not sure privacy violation is necessarily the right term to help people understand why long-term non repudiation is an undesirable property for some people.
It comes down to if a third party gets access to your emails (e.g. through a server compromise), should they be able to prove to a fourth party that the emails are legitimately yours, vs completely faked? Non repudiation through strong DKIM keys enables this.
Example: Third party is a ransomware gang who releases your emails because you didn't pay a ransom after your email server was compromised. Fourth party is a journalist who doesn't trust the ransomware gang, but also wants to publish juicy stories about your company if there is one, but doesn't want to risk their reputation / a defamation case if the ransomware gang just invented the emails.
Non-repudiation is virtually always undesirable in general-purpose messaging systems. Revealing to a stranger whether a message is valid is a concession to that stranger, not a benefit to the email's owner. This property is called "deniability" and most secure messaging systems go way out of their way to have it.
It's nobody else's business whether the emails in your inbox are valid or not, and that's basically all non-deniable DKIM signatures do: durable secure verifiable DKIM signatures are "security feature" with real-world value exclusively for attackers.
If you’re under Rule 26 discovery or disclosure requirements, it absolutely might be my business whether emails in your client are valid, but I suppose you could classify opposing counsel as an “attacker,” so you’re not wrong.
I get the verification the email actually came from the domain (i.e., someone, who has the credentials of an insider) vs. an email that was totally spoofed, from the outside, without any creds of the purported sender org. (Right?)
Hands on keyboard? You're right, absolutely not. But I can learn something useful via DKIM nevertheless.
> To satisfy DKIM's design goal, you only need a "current" DKIM key that is secure for a window of time. When that window of time passes, you rotate the secret and publish your own key, repairing (hopefully) much of the privacy injury.
If this occurs, is DKIM privacy safe? To make sure I understand, by publishing the private key after a period, that allows for repudiation, since any real email at that point could have been faked using the published private key?
The point of DKIM is to provide DURING TRANSIT that a server is the server is allowed to send emails from that domain. Once the transaction is completed, it doesn't matter if the key even continues to exist: it was verified during transit.
The fact that people do not rotate keys or use secure keys means that you can use it for other things as well, like detecting forgeries. It wasn't meant for humans, but for machines.
Repudiation doesn't work if the receive discards the email if it isn't signed, or marks it as DKIM validated when it is received. Many receivers using independent email providers like gmail, so the sender has no control over whether it happens or not. Both practices are common today, so it likely it does happen.
Rotating the key does make the claim "I have proof he sent it" a litter weaker, as it's no longer as easy to prove. But only a little as "your honour, it is marked as DKIM verified by the independent email provider he uses" is pretty solid.
Rotating the key and publishing the private key destroys the ability of an after-the-fact attacker (someone who pilfers older mails out of your inbox) to prove they obtained a real email. It's not an "only a little" thing; it's categorical.
Yes, it's a pretty good way of proving the server sent the email. That's all it proves. If the email came from gmail.com, it's up to Google to prove the person in the From: address composed the email. The signature can't prove that. Nonetheless almost everyone will accept that is what happened.
If Gmail received the email, it's likely they simply drop email with no or bad DKIM signatures. So if it's in your gmail inbox but a has signature that doesn't check out, to be categorically certain it was signed you would have to ask Google. But it's the same deal as the From: address - almost everyone is going to assume it was validly signed because that's gmail's policy.
TL/DR, I think your wrong. Rotating the key only weakens the proof slightly. The only thing that is destroyed is the cryptographic proof, but only in a fanatical cryptographers world is that the only form of acceptable proof. That fanatical cryptographer is wrong of course. Things outside of the mathematical certainty also matter. The rubber hose joke is funny, and the butt of that joke is fanatical cryptographers making that very assumption.
I really don't follow what you're trying to say here. The point is that the durable verifiable signature has no value to users, but lots of value to attackers; in other words: it only has value to attackers. People are confused because in a formal analysis, journalists getting stories from leaked mail spools are attackers; they are a thing secure messengers are designed to thwart.
> The point is that the durable verifiable signature has no value to users,
Apparently I'm the exception to that rule, because I have a DKIM extension installed on Thunderbird. I use it to do what you say isn't useful - as another way to check phishing messages long after they have been sent.
Until DKIM is universally enforced checking it after the fact will be useful. When DKIM is universally enforced rotating the keys won't matter to either the user or attacher, because both can be sure everything in the inbox (stolen or otherwise) was DKIM signed.
> I really don't follow what you're trying to say here.
It's simple. As things stand now much of the time you don't need a verifiable DKIM signature to know if the message had a valid DKIM signature when it was sent. Therefore it doesn't matter much to the user or attacker if keys were rotated - your "privacy violation" is still a thing whether the keys are rotated or not.
Unfortunately the "much" qualifier must be in there, and compounding that is the stuff that does skip through without being signed are almost always attacks on me - phishing or otherwise. Such messages are rarely sent from a bulk provider that insists on signing because it gets shut down promptly. The sender would probably prefer they were signed so the rejects weren't so frequent, but there are operating on low probability of people taking their message seriously so the even lower probability imposed by invalid DKIM signatures not a disaster.
Unfortunately for your argument legit email is now almost universally signed because the sender is relying on it getting through. If someone steals an inbox and an email that doesn't looked like spam was DKIM signed, then you can pretty safely assume it was validly signed when sent. Being able to validate the DKIM signature after the fact doesn't add much confidence.
Correct me if I'm missing something, but isn't tptacek's point that if the DKIM's keys are public, I can now just make up any email I want with a "correct signature" and claim it was sent from X and I found it in Y's inbox (for any X, Y). And therefore even if you really found it there you can't prove it. At that point you'd just be trusting the reputation of the accuser (perhaps a respected journalist, perhaps a shady criminal).
I'm not clear how the universal DKIM argument comes into play. Even if we were sure Google only accepts valid DKIM, you still have to trust that the accuser did in fact find it in the alleged Google inbox.
Whereas with the non-rotated key, the accuser has cryptographic proof their alleged email is genuine, because they couldn't have created it without the key.
> you don't need a verifiable DKIM signature to know if the message had a valid DKIM signature when it was sent.
You seem to be trying to say that "the fact that it was delivered proves it had a valid signature when it was sent".
That presupposes that the headers indicating when it was delivered are correct, or that it was delivered at all in the first place.
I don't think you understand the attack.
I sent Thomas an email admitting to something scandalous.
A few months later, Mallory pops the server Thomas's email is stored on, and extracts his mail spool.
Mallory wants to prove to a third party that the email is authentic and not a fabrication.
I know it's real.
Thomas knows it's real.
Mallory is pretty sure it's real.
Alice, a reporter for the Daily Bugle cannot verify it is real, rather than Mallory's forgery.
I can claim it's a forgery, and point out that Mallory could have made it up and generated the signature with the published key.
Now, I may have a problem if it were a crime rather than something merely scandalous because then Bob, an FBI agent, decides to subpoena some logs and maybe prove when it was sent, but even so, logs typically don't have message content or even a hash of the message content.
Consider this wrinkle: Thmoas's email provider is @gmail.com. Assume it is pretty well known the Gmail will only put email in his inbox if it is DKIM signed. (I run my own email home server. I can assure you this is true now unless you are someone like @debian.org. Unsigned email is simply dropped by most of the major players.)
You send the incriminating email. It's accepted by Gmail as it's DKIM signed. You rotate your DKIM keys. Mallory now steals in the @gmail inbox.
I can think of only two defences for you now. One is Google accepted the email without a valid DKIM signature - which you say is your main defence. The other is someone else sent the email by getting control of your email account / server / DKIM. I personally would find it much easier to believe you lost control of your email account than Google accepted a badly DKIM signed email from some random.
I still think this is a classic example of the XKCD rubber hose comic. The cryptographers are suffering from tunnel vision. They focus on exclusively on the well known properties of their beloved cryptography. It's odd they keep doing that. Modern cryptography is mature, well understood, and for the most part unbreakable. The weakest link is invariably elsewhere.
To satisfy DKIM's design goal, you only need a "current" DKIM key that is secure for a window of time. When that window of time passes, you rotate the secret and publish your own key, repairing (hopefully) much of the privacy injury.