7 ms·
Isn't deniability at odds with DKIM's goal? What would be the point of setting DKIM then? Sure, it helps with spam scores. But most companies rely on a major em
by GTP 2y ago
Isn't deniability at odds with DKIM's goal? What would be the point of setting DKIM then? Sure, it helps with spam scores. But most companies rely on a major email provider to send emails, so maybe they wouldn't have deliverability issues anyway?
- marcosdumay 2y agoYes. 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.
- matthewdgreen 2y agoI don't know what you're saying. Most email isn't encrypted so PFS wouldn't apply to the content of email messages. When you mention PFS are you talking about email encrypted with something like GPG/PGP? Or are you talking about PFS in the context of the TLS connections used to protect SMTP? I'm not sure what "deniability" refers to in your post and how you think people use email in ways that would contraindicate it. Once I understand what you're saying, I guess we could move on to who the demanders and promisers are and what you think they're doing.
- dfc 2y agoYou should read the blog post Prof. Green linked to. All of your questions are addressed there.
- GTP 2y agoYes, I've now read it and it answered those questions. But it also stumbled upon an easier possible solution without realizing it: if you wish to pretend you didn't send some emails, you can still claim that someone stole your password. Whether this claim will be believed or not, is independent of DKIM. 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.
- tptacek 2y agoIf you publish DKIM keys, you don't have to convince anybody that you were targeted by someone who stole your password, because your stolen email spool no longer reveals to attackers the authenticity of your emails, which is what you as a user want.
- GTP 2y agoBut you need to convince someone that someone targeted you and used the published key to forge an email. Where is the difference?
- tptacek 2y agoNo you don't. You just say "that email is fake and you can't prove otherwise", and you're right. What's almost more important is: there is no reason not to give users that affordance. They literally do not benefit from the non-repudiability of their email archive. The OTR paper got this right 20 years ago, and in the process basically created the entire field of secure messaging. It is wild to see people argue against it! They're basically pleading with email providers to collude with attackers to violate their privacy. https://otr.cypherpunks.ca/otr-wpes.pdf https://otr.cypherpunks.ca/otr-wpes.pdf
- GTP 2y agoI think here is where the problem isn't purely a technical one anymore. You're right that, from a legal perspective, there is a difference as the burden of proof would now be on someone else. But, if this actually matters or not, depends entirely on the situation. If you're a criminal trying to get away with something then the change in the burden of proof is all you need. If instead you're a politician trying to avoid some imbarassment, the situation isn't any different: you're claiming in both cases that someone is trying to frame you for something you didn't say. In one case, this person stole your password, in the other he/she used an old and by now publicly available DKIM key. But if people believe you or not (and this would be everything a politician would care about) depends on factors outside the scope of cryptography. Regarding OTR: IIRC it is based on a shared secret. This can work for IM, but it wouldn't scale for emails as it would pose the key distribution issues that made us discover public key cryptography.
- CodesInChaos 2y agoWhen using deniable authentication (e.g. Diffie-Hellman plus a MAC), the recipient can verify that the email came from the sender. But they can't prove to a third party that the email came from the sender, and wasn't forged by the recipient.
- jagged-chisel 2y agoMallory sends a message, forged as if from Alice, to Bob. How can Bob determine that it came from Alice and wasn’t forged by Mallory?
- commandersaki 2y agoThis is always a possibility but I'm guessing the happy path is the more likely believable scenario and could be verified OOB.
- tialaramex 2y agoNo, no, in these systems Alice and Bob both know a secret. Mallory doesn't know the secret, so, Mallory can't forge such a message. 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.
- TomK32 2y agoNow it makes sense why Alice was sending me that kitten in a mixer video. 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?
- reaperman 2y ago
- ralferoo 2y agoThat's not quite what he's saying. 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.
- tptacek 2y agoNo. 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.
- jonahx 2y ago> 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?
- ryan-c 2y agoRepudiation is the goal.
- rstuart4133 2y agoRepudiation 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.
- tptacek 2y agoRotating 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.
- matthewdgreen 2y agoDo take a look at the blog post I cited above, where I go into this in loads of detail. The TL;DR is that DKIM only needs to ensure origin authenticity for the time it takes to deliver an email, which is usually a few hours or a day at most. 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.
- dotancohen 2y ago> 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. Thank you for clarifying where the vulnerability chain begins and ends.