What's the problem with verifiable email? You can just delete old emails (if gmail or whoever archives them that's another problem). Most people probably operate under the assumption that email is verifiable in some way anyway. If you receive malicious email, isn't it a good thing to be able to verify where it came from? Doesn't that benefit senders and receivers alike? Or is this a case of "I want to verify you, but I don't want you to verify me"?
Sounds nefarious. Why would a sender want the recipient to verify authenticity while being able to deny it to a 3rd party. Sending threats or blackmail come to mind as top uses. Breaking confidentiality agreements is another. What's a legit honest above board use?
I don't see how this could be possible. If I have some information which I can use to prove that you were the sender, then I can just share the same information with a third party, and they can verify just the same.
Simple, I tell you that in my message, if it’s genuine, I’ll use the word “apple” somewhere.
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.
Yes it seems crazy, but besides the obvious "leak your own key" as other comments mentioned, this is actually possible. This is one of the biggest discoveries in cryptography in the last decades and its implications are still being researched. I dug around and found this article which seems to do a pretty good job describing the cryptographic concepts of "non-transferability" / "deniability" / "deniable authentication" for a lay audience: https://dinhtta.github.io/zkp/ Also: https://en.wikipedia.org/wiki/Deniable_authentication
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.
The idea is that for spam filtering purposes, you can prove this morning that the email I sent you this morning came from me, because I’m the only person who had the signing key on it. Anyone else could validate that too.
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.
Ok, so there's a time window where it's possible to prove that you were the sender. And if I use a qualified timestamp service to sign all messages arriving in my inbox, then I can prove that you were the sender indefinitely.
Something like that, as long as you can also prove I hadn’t published the key prior to that. If I publish at random times and to random URL, that may be challenging.
Yes, but then it also encroaches on ability to verify that you were the sender when receiving the original email. Basically, unless the recipient also checks whether the current DKIM key has been published, then they can't trust it because it may be published. If it's being published at random times and to a random URL, then it's nearly impossible to actually check.
So I agree that it brings deniability, but I don't agree that it still meets the original purpose of verifying the sender.
That’s all true, but I bet 99.99% of all email is delivered within a minute or so of being send. There are exceptions, of course, but in practice the whole thing is pretty fast.
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.)
> I bet 99.99% of all email is delivered within a minute or so of being send
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.
Imagine that yesterday, I had only one house key, and I left a copy of it in your mailbox so you could come into my house to borrow a cup of sugar while I was out. You can be sure I allowed it, because you know I had only one key.
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)
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.
