Me writing over 14 years ago: https://blog.jgc.org/2010/06/facebooks-dkim-rsa-key-should-b... This was doable 14 years ago for 512-bit keys.
DKIM deniability is a particular hobbyhorse of mine [1]. These short keys are obviously not the way to achieve it, but I view this kind of thing as a result of the muddled thinking that’s been associated with DKIM and the community’s lack of desire to commit to the implications of an all-email signing mechanism.
[1] https://blog.cryptographyengineering.com/2020/11/16/ok-googl...
DKIM might have convinced the witness sometimes though.
It is the lawyers appearing before the court that may attempt to play the person not the ball, by variously undermining or bolstering their standing as an expert at all.
* an example supporting the counter-example is simply another counter-example, and
* an example contradicting the counter-example is, by definition, also another counter-example.
Corollary: all examples that can be opposed or contradicted by counter-examples are themselves also counter-examples.
I would argue it should be taught in schools.
It's a basic life skill, to be aware of what it means and how common it is. How do you function in society being oblivious of these facts? Basically by perennially becoming a victim to these, or by becoming bitter.
Just knowing about it is half the battle.
I would also add other dark personality types with potential to cause you real harm to the list - BPD and NPD.
School yourself, save yourself a whole lot of bad surprises. Over a lifetime being aware of the existence of these means you are on the lookout for warning signs, and you learn to get better at picking up on warning signs faster.
Sometimes you've just gotta love those auto-shortened URLs: security.googleblog.com/2013/12/internet-wide-efforts-to-fight-email.html
Hopefully one day we'll win the fight.
PS. Of course y'all young'uns won't remember ...
Deniability and perfect forward secrecy are at odds with how people use email anyway. But that doesn't stop people from demanding both very loudly, and some people from promising them.
Spoofing is a better excuse than a stolen password only in the case of a single email. If there's a conversation spanning multiple messages, a spoofer wouldn't be able to properly answer the messages of the other party, as he doesn't receive them.
It is wild to see people argue against it! They're basically pleading with email providers to collude with attackers to violate their privacy.
Anyway, to further add to my point, depending on the context you don't even need to claim that someone stole your password. In the company where I am now , it is custom that, if someone finds out someone else didn't lock their computer, that someone sends an email (from the victim's account) to the whole office saying that the victim is going to bring cake to the office. DKIM is meant to prove that a message comes from an authorized server, but to prove the identity of the sender as well you need something more.
Edit: to be fair, I do get that with DKIM deniability gets harder. But I think that, for the average person, you would gain more in terms of spam and phising protection than what you loose. High profile targets have to take different security measures than the masses anyway.
Lying isn't a stronger defense to perform abuse than weak keys are for stopping abuse.
You change your password only after you realize it got stolen. If you didn't realize it, then it makes sense you didn't change it. And, depending on the specific case, you could find plausible explanations also for the other points.
You don't need a conversation to cause havoc.
Sure, but my point was different: let's say one of your teacher answered the spoofed email from the principal, you wouldn't be able to (properly) answer that email since you wouldn't receive it. So, in the case of an email exchange between two people, one can't claim his/her emails were spoofed, as the spoofer wouldn't be able to answer the other party's emails in a precise and on topic way. This is without even considering that, bh default, most email clients include the previous messages inside a reply. Meaning that the spoofer would somehow be able to know the other party's reply exactly word by word.
However, Bob can't prove to the world "Alice sent me this message saying she hates cats!" because everybody knows Bob knows the same secret as Alice, so, that message could just as easily be made by Bob. Bob knows he didn't make it, and he knows the only other person who could was Alice, so he knows he's right - but Alice's cat hatred cannot be proved to others who don't just believe what Bob tells them about Alice.
But seriously, in a case before a court or jury, wouldn't there be much more evidence? Down to your own lawyer sending a complete dump of your phone with all those Sandy-Hooks-conspiracies and hate messages to the opposing side?
DKIM's goal is that the receiving system can trust that the message presented to it has come from a host that knows the key, and so could sign it. At the time that message is received, you should be able to assume that only people authorised to send from that domain are able to do so.
By publishing older keys, you gain deniability back, because anybody could have forged the message and signed it. Even if you have timestamps that show when you received the message, the onus is one you to prove that those timestamps are not fabricated. This is a much harder problem because secrets can be revealed later but not forgotten.
To be able to prove that you did it fact receive the message on that date, you'd probably have to record e.g. the message ID, signature and timestamp (perhaps all encrypted with a key that you can reveal later) on a blockchain, which would then serve as proof of when the message was received. Even then, you'd still have to prove that the key hadn't been disclosed before that time.
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?
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.
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.
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.
It's not rocket science.
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 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.
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.
I'm missing something here. DKIM mostly proves an email from person@from.me 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.
Hands on keyboard? You're right, absolutely not. But I can learn something useful via DKIM nevertheless.
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.
The unintentional problem DKIM is causing is that it actually provides non-repudiation for many years. Those signed emails can sit in someone's mailbox for years, then get stolen by a hacker. The hacker can then blackmail the owner by threatening to dump the email trove, or for newsworthy targets they can just do it. Reasonable people (e.g., high-integrity newspapers, courts of law) will say "how can we trust that these stolen emails are authentic given that there's no chain of custody?" DKIM signatures nearly answer that question, which makes stolen emails much more valuable than they would be otherwise.
> Reasonable people (e.g., high-integrity newspapers, courts of law) will say "how can we trust that these stolen emails are authentic given that there's no chain of custody?" DKIM signatures nearly answer that question, which makes stolen emails much more valuable than they would be otherwise.
I don't think this is quite true. First of all, this is not only valuable to attackers, it's also valuable in a court of law to establish the truth of what happened. Secondly, it can be valuable to me to be able to prove that you sent me an email, even if you wished to deny it, also mostly in legal contexts.
More generally, authenticated communication has a long history of being considered a useful thing for society. Physical mail includes delivery confirmations where the receiver must sign for the receipt, proving to anyone that they did receive the letter. People would often add hard-to-forge personal seals to letters in even older days, that could prove to anyone that they were the ones who sent that document. And even common letters were usually signed rather, even when typewritten, again making it hard to later repudiate.
While I absolutely see the value in making it possible to securely send repudiatable email in some specific circumstances, I think having non-repudiatable email as the default is a net benefit to society, and has been the de facto standard for at least a few hundred years before email ever came along.
Repudiation of clear text messages looks like the easier implementation.
The fact that this is possible is some cryptography black magic.
But let’s say I publish that signing key tomorrow. Once I do that, you can’t prove I sent today’s mail because anyone could’ve used that published key tomorrow forget the signature.
So I agree that it brings deniability, but I don't agree that it still meets the original purpose of verifying the sender.
So there’s some threat modeling, too. Are you trying to email someone highly adversarial? Maybe you’re at a law office or such and that’s the case! This wouldn’t help a lot there. Not everyone is immediately forwarding all inbound mails to a timestamping service though.
(I don’t have skin in this game, so I’ll probably duck out after this. I don’t have opinions on whether publishing old DKIM keys is good or bad.)
No doubt that is true. However, given the total volume of email, even that tiny, tiny remaining fraction still represents actual mail with legitimate use-cases. So it's good to bear that fact in mind and not roughly implement 80-20 stuff that tramples on those.
Today, I made 3 copies of my housekey and gave them to friends. You still know that I was the one that allowed you entry into my house, but you can not prove to anyone else that I was the one that made the copy, because there are now 3 other people that could do that.
(For this example, imagine I made the key copies at home and didn't go to a locksmith who could verify when they were made, since we don't need a locksmith to do software crypto)
I.e. a symmetric key is shared between you and me. If I receive a message with that key, I know it's from you because the key is only known by you and me, and I know I wasn't the sender, so it must be you. But any third party can only say that the message was by one of us.
You tell me that you’ll use the word “banana”.
Provided no-one except you knows that my secret word is “apple”, you know the message came from me.
But it’s perfectly possible for you to fake a secret message and sign it “Love d1sxeyes, P.S. apples”, and so our approach only works between the two of us. A third party probably can’t even confirm that “apples” was the correct keyword, and even if they could, that can only prove that one of us wrote it, they can’t definitively say which one of us.
Now extrapolate this to using some more sensible mechanism than dictionary words.
If Alice and Bob each have a public/private key pair, they can do a diffie-hellman key exchange to form a common secret. If they use that secret to authenticate a message, then it can be shown that only Alice or Bob sent the message. If you're Alice or Bob, this is what you want to know --- either you or your corespondent sent it, and if you didn't send it, your correspondent did.
But if Alice or Bob asks Carol to validate it, Carol can only determine that Alice or Bob sent it, and perhaps not even that. Anyone in possession of the secret used to authenticate the message can also make a message that would be deemed authentic. If you have participation of Alice or Bob, you can show that the secret was derived from DHE with Alice and Bob's key pairs, but that's all.
This is nifty and useful, but it's more appropriate for end to end communication, which is not the domain of DKIM. Email is a multi point store and forward system, where each point would like to know if a message is authentic; deniability like this would probably mean either
a) only the final destination could determine authenticity and therefore intermediates would not be able to use authenticity as a signal to reject mail
b) only the first intermediate could determine authenticity; it could be used to reject mail, but the end user would have to trust the intermediate
Both of these are workable systems, but DKIM provides that all intermediates and the end user can know the mail was authorized (to some degree) by the origin system.
What's more dangerous is that a jury wouldn't know the difference.
If there is some mail from my addr, with a valid DKIM signature, it proves nothing: - perhaps the mail was sent by somebody else on the same plateform, but in my name (identity usurpation of the user part of the mail) - perhaps somebody got illegal access to my email account, without me knowing - .. ?
In no case it proves that I, as a human, sent this email.
But of course, justice is a fiction that cannot exist: there is no justice, only probabilities (and feelings :( ).
> The fix would cost you basically nothing, and would remove a powerful tool from hands of thieves.
Maybe that was true a while ago, but it becoming much less true now. Most people and organisations outsource the email handling to the likes of Google and Microsoft. They tend to reject email that isn't DKIM signed, and add a "DKIM validated" header to those that are. "Tend" is probably too weak a word now - email that isn't signed isn't likely to be delivered.
So the mostly likely scenario now is "someone steaks email that can no longer be DKIM validated, but it is possible prove it was DKIM validated when it was received". If that's true rotating keys doesn't help.
https://www.wired.com/2012/10/dkim-vulnerability-widespread/
So we went to a few weeks to 8h in 14 years give or take
> We chose a server with 8 dedicated vCPUs (AMD EPYC 7003 series) and 32 GB of RAM from Hetzner
Not very beefy really. Beating this time is easily in range of, what, millions of people high end gaming machines?
I stand corrected