back
136 comments
So for work I consult on email security and every time this article pops up I get texts from everybody asking for my opinion. So here we go.

Disclaimer: opinions are my own.

A DKIM signature does not prove that an individual sent the email, the key is not personal. A DKIM signature proves that the sending service is a delegated sender for the domain. Meaning that a correct DKIM signature proves that the part after the '@' symbol in the sender address is authentic. Not the part before that. If you want to use a personal signature, you can use S/MIME.

If you are a delegated sender for the domain, then you can use any sender name (the part before the '@' in the sender email address). This is how email works. The password that is typically required to authenticate with your outbound SMTP service if only enforced by that host.

So an email with sender address jane@example.com that is DKIM signed only proves that the email was send by a host that is a allowed to send email on behalf of example.com. It does not prove in any way that the email was sent by Jane.

Also, as others have mentioned, none of the email service providers will give you the private keys. I'd like to add that in most cases this won't even be possible, due to the use of HSMs.

So the proposed scheme would only work in a situation where you are owner of the DKIM key (thus in practice where you are the owner of the host sending the email), and where you also own the domain. It is trivial for a prosecutor to prove the owner of the domain, or the owner of the host that used the DKIM key. No amount of publishing keys will help you deny that ownership.

In my opinion it makes no sense in signing your email (whether it is S/MIME or DKIM) to prove that the email is authentic, and then complaining that there is no way to deny that the email is authentic once stuff goes bad.

I think this is missing the trust that the delegated sender adds. If you have an email with a DKIM signature from Gmail, then either:

a. The email is authentic.

b. Gmail has risked its reputation to "forge" the signature of an email it never sent.

That's strong evidence that the email is authentic! On the other hand, if Gmail were to publish their old DKIM keys, anyone with technical skills could have forged that signature.

As for why repudiation is desirable for emails, think protesters. They want to verify that the emails they receive are really from each other, but minimize their exposure in case the emails leak.

It's a common property for secure messaging systems, and I don't see why emails shouldn't have it too.

Deniability is a useful characteristic in cryptographic protocols: the idea is the authenticity of the message can be proved to anyone who checks before the key is published (i.e. likely the intended recipient of the message), but not to someone who checks later (i.e. likely someone who may wish to use the contents of the message against you). It's something Signal's chat protocol aims to achieve, for example.
> It is trivial for a prosecutor to prove the owner of the domain, or the owner of the host that used the DKIM key

The point of publishing the keys is that _anyone_ can then sign messages, making "ownership of the domain" a meaningless factor, no matter how much you can prove it.

>In my opinion it makes no sense in signing your email (whether it is S/MIME or DKIM) to prove that the email is authentic, and then complaining that there is no way to deny that the email is authentic once stuff goes bad.

We all understand that really only the domain part is being authenticated, but if people believe in the good user identity and authentication practices of the sending domain then it's going to hard to rebut the presumption that the email is from the apparent sender.

If we posit that the purpose of DKIM signatures is preventing the injection of forgeries in the MTA chain, then authenticity is only an important property from the time that the message is sent until the time it reaches its addressed recipient. After that point, it's a bug, because long-term non-repudiation is not a purpose of DKIM.

Once a particular message is no longer traversing the network, there is no value (for DKIM purposes) in preserving the secrecy of the signing key.

OpenDKIM allows you to setup signing tables which can include individual keys for individual sending addresses.

So you're kinda right in the sense it's mostly authenticating the sending service's configuration and relationship to the domain, but kind of wrong on the front where the part before the @ isn't fundamentally authenticated. It is.

The User/User-Agent decoupling issue is still omnipresent, and adds a fundamental layer of uncertainty, that you are correct in. The fact we still seemingly need to grind that in to the uninitiated at times feels like there needs to be a cure to magical thinking formulated more than anything else.

> In my opinion it makes no sense in signing your email (whether it is S/MIME or DKIM) to prove that the email is authentic, and then complaining that there is no way to deny that the email is authentic once stuff goes bad.

It is also rather futile, since the prover can get the messages timestamped (myriads of ways, myriads of platforms), perhaps even steganographically in the correspondence, before the key is rotated.

the denialists can still rotate after shorter and even shorter intervals, but at some point the client software can't keep up and verify the email provider during usage, or rather resulting absence of usage...

it's pretty sad when technologists cave in under pressure from governments, politicians, lawyers and big firms keeping the lid on scandals... reducing the usage of cryptography to a purely symbolic cargo cult token or gesture...

Cryptography configured for exhibition only... but not in any court.

> every time this article pops up

I don't think this is the same article of which you're thinking. This is a tool to rotate DKIM keys and publish the old ones (in a sense, a scheme that replaces revocation).

> So an email with sender address jane@example.com that is DKIM signed only proves that the email was send by a host that is a allowed to send email on behalf of example.com. It does not prove in any way that the email was sent by Jane.

You should probably stop "consulting on email security" if you don't understand that a DKIM-signed message proves the mailhost was authorized, and at least some of the headers could easily prove who sent the message.

> in most cases this won't even be possible, due to the use of HSMs.

Most holders of keys do not own an HSM.

Thank you for saving me the time on this. I was about to echo the same.
This came up with the hunter biden laptop, DKIM doesn't really validate that you sent an email, but that an email was sent through that server at some point in time when said signing key was still being used.

i.e. I demonstrated to others that I could have a DKIM signed email sent through gmail that was from a spoofed from: and it passed all DKIM tests (i.e. telnet gmail smtp server 25 (well with ssl, so openssl connect or something). smtp auth and do the standard MAIL FROM "SoSo <so@so> RCPT TO so@so data...... and it will look like a legit mail sent from SoSo.

DKIM's job isn't to protect against that.

Q: If 2FA is enabled on a Google account, does SMTP AUTH still work?

I've just tested this, I generated a new app password in my Google Account and used that to send Gmail from Python.

Works fine when sending "from: <me@gmail>" with the app password, yet I can't change the sender since the SMTP auth then fails

"5.7.8 Username and Password not accepted. Learn more at https://support.google.com/mail/?p=BadCredentials"

Wasn't it also Hillary Clinton's emails that had DKIM and they denied that they wrote any of them? If that were the case it would mean someone has full access to that email system for years and sent all those emails through it.
I don't buy this idea:

> As a user, you probably don’t want your emails to be non-repudiable. (Other people might want to be able to prove you sent some email, but your email system ought to serve your interests, not theirs.)

Other people being able to verify that an email really was sent by me does serve my interests, because such verification establishes trust. That's like claiming signing a contract isn't in your interest, because others will be able to prove that you agreed to its terms.

There are very few legitimate situations where you don't want non-repudiation (and in most of these, you shouldn't use a standard email system anyway), while in many cases, non-repudiation is legitimately valuable – for both sender and receiver.

I was a expert witness on a case where a dad had modified an email as proof to drop their daughter out of school. The mom was quite pissed that he did this. I used the DKIM keys to prove the email she submitted was true and his version was not the original. It was a fun case.
> Other people being able to verify that an email really was sent by me does serve my interests, because such verification establishes trust.

DKIM, the technology considered by the article, does not prove this. The D stands for domain; it asserts nothing about the user that may have sent the email. Even if the domain is yours, you might delegate to another service or two, or you may have more than one user, or some automation in place. In any case, the recipient has little, if any, way to verify that and in all likelihood doesn't care that much; if they did, they wouldn't be relying on DKIM.

> There are very few legitimate situations where you don't want non-repudiation...

As a service provider, I'd probably want this. If it gets me out from the middle of someone else's dispute and doesn't have an ill effect on the service otherwise, I'd welcome it.

> Other people being able to verify that an email really was sent by me does serve my interests, because such verification establishes trust. That's like claiming signing a contract isn't in your interest, because others will be able to prove that you agreed to its terms.

Are you saying that you do want people who are not your intended recipient(s) to be able to check copies of your emails to be able to verify that you actually wrote/sent those emails? Do you have an example of when this comes up in practice?

If you mean that you do want your recipient(s) to be able to verify your emails, the article is in agreement with you. The article states:

> When you send an email, that’s between you and the recipient. Normally you don’t intend for anyone, anywhere, who happens to get a copy, to be able to verify that it was really you that sent it.

where "anyone, anywhere, who happens to get a copy" is to say "an arbitrary person other than your intended recipient(s).

Most people want messages sent to them to be non-repudiable. Otherwise they can be harassed and threatened with impunity. This sort of thing only seems like a good idea when you don't remember that a message has both a sender and a receiver.
Then I think you'll have to use pgp or some other mechanism one layer up. E-mail ain't the way to do it, it's not built into the current protocol as it stands.
Sure. I don't know if that's the case only for Gmail, but after email is received, generally, it's verified and results, at the point of receiving are stored on your email server. He's talking about verification after that initial verification. And if you want your emails to be verified, you should be using GPG/PGP/S.MIME or other signing system anyways. DKIM only verifies server, not user.
SPF says which IP adresses are authorized to send email for a domain. DKIM should increase confidence that email is sent by authorized service on servers with those IP addresses (eg. Postfix) as opposed to unauthorized ones (eg. telnet). Finally, DMARC instructs receiving servers how to act on receiving email for a domain regarding validity of SPF and DKIM. It is up to receiving servers to respect this instruction or not.

None of the above has anything to do with particular email message authenticity. Mechanisms for email authenticity, or additionally confidentiality, are S/MIME and PGP, where user controls the key, and it is up to them to make sure it doesn't leak.

I am providing email service to close to thousand users on dozens of domains over the course of fifteen years. The article does not make much sense to me from either postmaster's or mail user's point of view.

> None of the above has anything to do with particular email message authenticity.

Only if you're on a shared email hoster. If you're the only one that has access to the mail server's signing keys, it's gonna be real hard to convince anyone that someone else signed that email.

If this is not done, your emails are “non-repudiable”, meaning that if they are leaked, anyone (eg, journalists, haters) can verify that they are authentic, and prove that to others. This is not desirable (for you).

Not convinced, the bigger problem today seems to be that someone claims that you sent something you didn't and if you do the above you can't disprove that.

You could sign your emails, but then the whole point of publishing the private keys is negated anyway...

Double DKIM?

The first signature for your future proof-of-authorship needs and the second for regular DKIM mechanisms to accept your email?

The first key isn’t ever published but you keep it if you need to prove your email was written by you.

The second key is rotated regularly with the private key published so that always have the ability to claim “I didn’t write that”.

> You could sign your emails, but then the whole point of publishing the private keys is negated anyway...

Not really. The point is to deliver emails. Once it's delivered, it doesn't matter as much.

OK, rotating the DKIM keys allows someone to send an email and then later claim that the email was a forgery. But the fact that the DKIM keys are rotated is going to be generally known. So how could this possibly work?

Someone comes to you and claims that a particular email was forged. They have no evidence of this forgery and no evidence that someone was even motivated and capable of doing such a forgery. You check and see that DMIM rotation is being done. Wouldn't the fact that there was a system set up specifically to allow someone to send an email and then lie about it make you very suspicious that they had done exactly that?

Forwarding an the email to a third party entirely defeats this scheme, doesn't it?

I don’t think this is as cut and dry as the author would have you believe.

Given the options, I think I would rather have the class of problems that come with being able to prove where an email originated instead of the problems that arise from not being able to do so.

Proof protects a lot of innocents from bad actors in a lot of ways. Lack thereof protects whistleblowers and the like. It’s not a totally clear win one way or the other. I just suspect the prior helps more people.

I have a big soft spot in my heart for idealistic crypto stuff like this. Everything the author argues is true...but there's no way in hell commercial email providers would actually publish their private keys. The only way it would be in their interest to make it easy to forge old emails would be if a substantial portion of users demanded it, and that's never going to happen.
Here’s the thing about deniability: even if you successfully remove all cryptographic proof of provenance, actually denying it is still asserting a frame job. That’s useless if the party you’re trying to mislead either is or trusts the data source, like, say, in the case of police surveillance, hackers, nation-state attackers…

I think the real solution to future breaches is ephemerality, which is why it’s critical for any secure messaging service to not only implement all-participant auto-delete, but to also make it easy to opt in to only for specific messages, since that brings the cost:benefit down to a point that it’s actually used.

The whole idea of DKIM and SPF checks and even DMARC policy is to fulfill the “integrity” part of the email communication by authenticating it to prevent unauthorized parties to send emails on behalf of a domain they don’t own. For DKIM, the mail you send will have the public key, then the header is signed with the mail server private key, similarly, the recipient side use the public key to verify the private was used, and to make sure the email was not tampered with in the way. Now, that boring theory to show that the idea is to prove it was you (the domain) who sent it -keep in mind DKIM won’t prevent spoofing, it’s meant to prevent spam, you should combine DKIM with your DMARC policy to make sure the domain in Form is not altered-, so trying to find a way that you can says later “it probably wasn’t me” defeats the purpose of these integrity checks, and doesn’t even make sense to be honest, if you’re too concerned about leaked emails, encrypted it with GPG, still not the most optimal solution since meta-data is still leaking, at the end of the day, emails are not meant for secure communications.
My previous comment was flagged, but I'm happy to restate.

The author doesn't understand what repudiate means, and therefore all the arguments are nonsensical.

To repudiate means, according to Cambridge dictionary "to refuse to accept something or someone as true, good, or reasonable"

So, when a transaction or email is repudiated, it means that someone is claiming that they didn't do it, despite the fact that it was done.

Non-repudiation is a characteristic of a system whereby a user of the system will find it difficult or "impossible" to repudiate that they did an action in that system.

So when the author claims in a title that "Non-repudiation of emails is undesirable" they are getting the words and meaning mixed up.

It is repudiation that is undesirable, and that's why non-repudiation is such an important characteristic of some types of system.

Rotating (and removing old keys from DNS) without publishing the private keys would already make it really hard.

For proving an old signature you'd lack an _authentic_ source for the signing public key that could only really be a dump of the historic DNS trace with all DNSSEC signatures (i.e. gmail does not use it).

Publish your ssh private keys!
The article advocates publishing old DKIM keys in order to provide deniability. You create a new DKIM key, publish the old one. With the old dkim key forging an old email is relatively easy.

Someone takes you to court and submits an old email that you sent as evidence. You can demonstrate that it is possible that anyone could have signed that email using the now-published DKIM key.

It is interesting that you can do this. A question is whether and when you would want to do so. Someone points out that good or bad conspirators might want to this: you send out anti-Putin emails and can deny it. Other ones?

Another point seems to be that DKIM is really designed not to verify emails, but to verify email senders.

<humor> Understanding this, I wonder if there are other things you can do with email using the same DKIM signing kind of mechanism. Like what about an OSIM signature, that uses a key only issued to email services that are not Google or Hotmail or one of the other big email people. If the message does not come from an OSIM host, then the email is delivered but goes into a o_spam folder? <end humor/>

If we retain a functional society with reasonable rights for all aren't the "victims" of non-repudiation going to be virtually exclusively bad actors?

People at real risk should probably be using something more secure like signal whereas people like US senators using a platform to communicate that can't be audited at need should probably go straight to prison on principal.

Is this actually a problem in practice?

How many people have presented forged emails as real without a DKIM signature, and had the press say "nah, we're not going to report on that because DKIM is missing"?

Presumably there is a transitional period during which the new DKIM key becomes active and the old inactive. Will some legitimate mails fail verification during that period?
Is there any service which automatically indexes and archives DKIM keys?

It could be very valuable to check the authenticity of old e-mails.

Publish your private keys and be considered responsible for what is signed with them, simple really :)

I am not a fan of blockchains but this is a rare case where they could be used to prove that the message is authentic by publishing the hash of the message (including the signature) in it. If the DKIM private key was published after the message was added to the blockchain then the message was clearly legitimate.

This whole meme started because people could use DKIM to verify that Hunter Biden really did send his incriminating emails while we were all supposed to think they were russian disinfo.

Some people are literally so politics poisoned that they can't see that it cuts both ways. I can't wait until DKIM is used to prove something bad about Trump so everyone can flip their position on DKIM.

It isn't going to change anything, politics poisoned brains won't see the irony. But it's always funny to see anyway.

Awww yisss, publish all the private keys, let’s have a DKIM-verified phishing bonanza while we are at it, too!
"You should be rotating the key regularly and automatically, and publishing old private keys."

OK, I read the article, I operate my own email server and nothing I read convinces me I should do what they're suggesting.

Captcha Check

Hello, you've been (semi-randomly) selected to take a CAPTCHA to validate your requests. Please complete it below and hit the button!

SPF is enough (and it is built-in with plain no-DNS SMTP servers).
A global database of which DKIM keys were served by which mail domains on which day would not be hard for anyone to create and would make it possible to cryptographically validate the sending host after the fact, even for hosts that rotated and published old DKIM key pairs, surely? This technique to make old emails repudiable doesn't seem very robust.