The Internet is a dangerous place in the best of times. Sometimes Internet engineers find ways to mitigate the worst of these threats, and sometimes they fail. Every now and then, however, a major Internet company finds a solution that actually makes the situation worse for just about everyone. Today I want to talk about one of those cases, and how a big company like Google might be able to lead the way in fixing it.
This post is about the situation with Domain Keys Identified Mail (DKIM), a harmless little spam protocol that has somehow become a monster. My request is simple and can be summarized as follows:
Dear Google: would you mind rotating and publishing your DKIM secret keys on a periodic basis? This would make the entire Internet quite a bit more secure, by removing a strong incentive for criminals to steal and leak emails. The fix would cost you basically nothing, and would remove a powerful tool from hands of thieves.
That’s the short version. Read on for the long.
What the heck is DKIM, and how does it protect my email?
Electronic mail was created back in the days when the Internet was still the ARPANET. This was a gentler time when modern security measures — and frankly, even the notion that the Internet would need security — was a distant, science-fiction future.
The early email protocols (like SMTP) work on the honor system. Emails can arrive at your mail server directly from a sender’s mail server, or they can pass through intermediaries. In either case, when an email says it comes from your friend Alice, you trust that it comes from Alice. What possible reason would there be for anyone to lie?
The mainstream adoption of email showed that this attitude was pretty badly miscalibrated. In the space of a few years, Internet users discovered that there were plenty of people who would lie about who they were. Most of these were email spammers, who were thrilled that SMTP allowed them to impersonate just about any sender — your friend Alice, your boss, the IRS, a friendly Nigerian prince. Without a reliable mechanism to prevent that spamming, email proved hilariously vulnerable to spoofing.
To their great credit, email providers quickly realized that email without sender authenticity was basically unworkable. To actually filter emails properly, they needed to be able to verify at least which server an email had originated from. This property has a technical name; it’s called origin authenticity.
The solution to the origin authenticity, like all fixes to core Internet protocols, is kind of a band-aid. Email providers were asked to bolt on an (optional) new cryptographic extension called Domain Keys Identified Mail, or DKIM. DKIM bakes digital signatures into every email sent by a participating mail server. When a recipient mail server obtains a DKIM-signed email claiming to originate from, say, Google: it first looks up Google’s public key using the Domain Name System (DNS). The recipient can now verify a signature to ensure that the email is authentic and unmodified — the signature covers the content and most of the headers — and they can then use that knowledge as an input to spam filtering. (A related protocol called ARC offers a similar guarantee.)
Of course, this approach isn’t perfect. Since DKIM is optional, malicious intermediaries can “strip off” the DKIM signatures from a given email in an effort to convince recipients that the email was never DKIM-signed. A related protocol, DMARC, uses DNS to allow mail senders to broadcast preferences that enforce the checking of signatures on their email messages. These two protocols, when used together, should basically wipe out spoofing on the Internet.
What’s the problem with DKIM/ARC/DMARC, and what’s “deniability”?
As an anti-spam measure there’s nothing really wrong with DKIM, ARC and DMARC. The problem is that DKIM signing has an unexpected side effect that goes beyond its initial spam-filtering purpose. Put simply:
DKIM provides a life-long guarantee of email authenticity that anyone can use to cryptographically verify the authenticity of stolen emails, even years after they were sent.
This new non-repudiation feature was not part of DKIM’s design goals. The designers didn’t intend it, nobody discussed whether it was a good idea, and it seems to have largely taken them by surprise. Worse, this surprise feature has some serious implications: it makes us all more vulnerable to extortion and blackmail.
To see the problem, it helps to review the goals of DKIM.
The key design goal of DKIM was to prevent spammers from forging emails while in transit. This means that receiving servers really do need to be able to verify that an email was sent by the claimed origin mail server, even if that email transits multiple untrusted servers on the way.
However, once mail transmission is complete, the task of DKIM is complete. In short: the authenticity guarantee only needs to hold for a short period of time. Since emails generally take only a few minutes (or hours, in unusual cases) to reach their destination, the authenticity guarantee does not need to last for years, nor do these signatures need to be exposed to users. And yet here we are.
Until a few years ago, nobody thought much about this. In fact, in the early DKIM configurations were kind of a joke: mail providers chose DKIM signing keys that were trivial for motivated attackers to crack. Back in 2012 a security researcher named Zachary Harris pointed out that Google and several other companies were using using 512-bit RSA to sign DKIM. He showed that these keys could be “cracked” in a matter of hours on rented cloud hardware, and then used these keys to forge emails from Larry and Sergey.
Providers like Google reacted to the whole “Larry and Sergey” embarassment in the way you’d expect. Without giving the implications any serious thought, they quickly ramped up their keys to 1024-bit or 2048-bit RSA. This stopped the forgeries, but inadvertently turned a harmless anti-spam protocol into a life-long cryptographic authenticity stamp — one that can be used to verify the provenance of any email dump, regardless of how it reaches the verifier.
You’re crazy. Nobody uses DKIM to authenticate emails.
For better or for worse, the DKIM authenticity stamp has been widely used by the press, primarily in the context of political email hacks. It’s real, it’s important, and it’s meaningful.
The most famous example is also one of the most divisive: back in 2016, Wikileaks published a batch of stolen emails stolen from John Podesta’s Google account. Since the sourcing of these emails was murky, WikiLeaks faced a high burden in proving to readers that these messages were actually authentic. DKIM provided an elegant solution: every email presented on Wikileaks’ pages publicly states the verification status of the attached DKIM signatures, something you can see today. The site also provides a helpful resource page for journalists, explaining how DKIM proves that the emails are real.
But the Podesta emails weren’t the end of the DKIM story. In 2017, ProPublica used DKIM to verify the authenticity of emails allegedly sent to a critic by President Trump’s personal lawyer Mark Kasowitz. In 2018, the Associated Press used it once again to verify leaked emails tying a Russian lawyer to Donald Trump Jr. And it happened again this year, when the recipients of an alleged “Hunter Biden laptop” provided a single 2015 email to Rob Graham for DKIM verification, in an effort to overcome journalistic skepticism at the sourcing of their information.
Some will say that DKIM verification doesn’t matter, and that leaked emails will be believed or rejected based on their content alone. Yet multiple news organizations’ decision to rely on DKIM clearly demonstrates how wrong that assumption is. News organizations, including Wikileaks, implicitly admit that questionable sourcing of emails creates doubt: perhaps so much so that credible publication in a national news organization is impossible. DKIM short-circuits this problem, and allows anyone to leap right over that hurdle.
The Associated Press even provides a DKIM verification tool.
In short, an anti-spam protocol originally designed to provide short-lived authenticity for emails traveling between email servers has mutated — without any discussion or consent from commercial mail customers — into a tool that provides cryptographically undeniable authentication of every email in your inbox and outbox. This is an amazing resource for journalists, hackers, and blackmailers.
But it doesn’t benefit you.
So what can we do about this?
DKIM was never intended to provide long-lived authenticity for your emails. The security guarantees it provides are important, but need only exist for a period of hours (perhaps days on the outside) from the moment a mail server transmits your email. The fact that DKIM can be used to prove authenticity of stolen email from as long ago as 2015 is basically a screwup: the result of misuse and misconfiguration by mail providers who should know better.
Fortunately there’s an easy solution.
DKIM allows providers to periodically “rotate”, or replace, the keys that they use to sign outgoing emails. The frequency of this rotation is slightly limited by the caching behavior of the DNS infrastructure, but these limits aren’t very tight. Even a big provider like Google can easily replace its signing keys at least every few weeks without disrupting email transit. This sort of key replacement is good practice in any case, and it represents part of the solution.
Of course, merely replacing DKIM keypairs does nothing by itself: smart people on the Internet routinely archive DKIM public keys. This is, in fact, how a 2015 Google email was verified in 2020: the key that Google used for verifying DKIM emails during that long-ago time period (a single key was used from 2012-2016, seriously Google, this is just malpractice!) is no longer in use, but has been cached in various places on the Internet.
Solving this problem requires only a small additional element: Google needs to publish the secret key portion of its keypairs once they’ve been rotated out of service. They should post this secret key in an easily-accessible public location so that anyone can use it to forge alleged historical emails from any Google user. The public availability of Google’s signing key would make any new email leak cryptographically deniable. Since any stranger would have been able to forge a DKIM signature, DKIM signatures become largely worthless as evidence of authenticity.
(People who run their own mail servers can achieve the same thing automatically by using this awesome script.)
Google could launch the process right now by releasing its ancient 2016-era private keys. Since the secrecy of these serves literally no security purpose at this point, except for allowing third parties to verify email leaks, there’s no case for keeping these values secret at all. Just dump them.
(A paranoid reader might also consider the possibility that motivated attackers might already have stolen Google’s historical secret DKIM keys. After all, DKIM signing keys aren’t exactly the crown jewels of Google’s ecosystem, and are unlikely to receive Google’s strongest security efforts. By keeping its keys secret in that case, Google is simply creating a situation where specific actors can counterfeit emails with impunity.)
But DKIM authenticity is great! Don’t we want to be able to authenticate politicians’ leaked emails?
Modern DKIM deployments are problematic because they incentivize a specific kind of crime: theft of private emails for use in public blackmail and extortion campaigns. An accident of the past few years is that this feature has been used primarily by political actors working in a manner that many people find agreeable — either because it suits a partisan preference, or because the people who got “caught” sort of deserved it.
But bad things happen to good people too. If you build a mechanism that incentivizes crime, sooner or later you will get crimed on.
Email providers like Google have made the decision, often without asking their customers, that anyone who guesses a customer’s email password — or phishes one of a company’s employees — should be granted a cryptographically undeniable proof that they can present to anyone in order to prove that the resulting proceeds of that crime are authentic. Maybe that proof will prove unnecessary for the criminals’ purposes. But it certainly isn’t without value. Removing that proof from criminal hands is an unalloyed good.
The fact that we even have to argue about this makes me really sad.
Timestamping, better crypto, and other technical objections
Every time I mention this idea of dumping old secret keys, I get a batch of technical objections from people who make really good points but are thinking about a stronger threat model than the one we generally face.
The most common objection is that publication of secret keys only works if the signed emails were obtained after the secret keys were published. By this logic, which is accurate, any emails stolen and published before the DKIM secret key is published are not deniable. For example, if someone hacks your account and immediately publishes any email you receive in real-time, then cryptographic verifiability is still possible.
Some even pose a clever attack where recipients (or hackers who have persistent access to your email account) use a public timestamping service, such as a blockchain, to verifiably “stamp” each email they receive with the time of receipt. This allows such recipients to prove that they had the signed email before the DKIM secret key became public — and checkmate.
This is a nice theoretical hack and it’s clever, but it’s also basically irrelevant in the sense that it addresses a stronger threat model. The most critical issue with DKIM today is that DKIM signatures sit around inside your archived mailbox. This means that a hacker who breaches my Gmail account today can present DKIM signatures on emails I sent/received years ago. Publishing old DKIM secret keys would take care of this problem instantly. Fixing the theoretical “real-time hacker” scenario can wait until later.
Another objection I receive sometimes is that cryptographic authentication is a useful feature. And I agree with that, in some settings. The problem with DKIM is that no customers asked for this feature as a default in their commercial mail account. If people want to cryptographically authenticate their emails, there exists a lovely set of tools they can use for this purpose.
Finally, there’s a question of whether the DKIM deniability problem can be fixed with exciting new cryptography. As a cryptographic researcher, I’m enthusiastic about that direction. In fact: my co-authors Mike Specter and Sunoo Park and I recently wrote a paper about how a long-term fix to DKIM might work. (Mike wrote a great blog post about it.) I don’t claim that our solution is necessarily the best approach, but I’m hoping that it will inspire more work in the future.
But sometimes the best solution is the obvious one. And right now, Google as the largest commercial mail provider, could make a huge impact (and protect their customers against future leaks) by doing something very simple. It’s a mystery to me why they won’t.
A Few Thoughts on Cryptographic Engineering 
Maybe they’d like to keep their archive on hand in case they need to helpfully leak an incriminating email or two of their own someday
If google releases the security key they should be torn apart and prosecuted under the RICO act as part of organized crime and under the constitution as Treason. It will likely make verifying existing emails for prosecuting terrorists and other heinous crimes impossible! Terrorism organizations will immediately start using gmail for recruiting and NO ONE could prove the emails were authentic! The author of this idiocy should be FIRED for aiding and abetting terrorists, enemies of the U.S., and criminals!
Google can implement filters/use AI to prevent terrorist recruiting. Plus, Google is an international company, so only aiding the US isn’t right either. Until today, I didn’t know people like the author of this comment could be so stupid.
Since this non-repudiability via DKIM is an accident, nobody promises the government that the accident will keep happening. You’re _SUPPOSED_ to rotate DKIM keys. Publishing the private key only improves the rotation.
Ok I never thought much about this. But what about that people should be able to authenticate the email? In terms if I’m a police and I get access to some emails this way I can verify them. Other ways I can not and maybe there would be no legal way to get access to them. This would mean without access to the mail servers emails could never be used as proof of something. For commercial and other usages this could be a problem also.
I know we all want our freedom but should we have it always?
This would give you instant deniability in lots of cases and maybe that’s not a good thing?
If you want your emails to be verifiable, you can always separately sign them, using GPG or whatever. If the police are unable to legally get access to the information they want, that is a feature and the system is working as designed.
Partly this. Currently, the police can covertly hack your server or bribe your provider to divulge your mail, and then claim they found it on a driveway and yet show the authenticity by the DKIM signature.
If DKIM is made deniable, the police doesn’t really lose anything. They can still get a warrant and acquire the contents your mailbox legally. By doing so they know where they got it from and don’t need any further proofs of it—it’s all in the report and we can testify the report is true; and also here’s the testimony of your administrator who says the last Received header is accurate and was authenticated in transit.
It’s only when you can’t otherwise show the authenticity where the DKIM helps, and you can sign your mail yourself if you need it for business reasons when you don’t trust your provider. Don’t rely on anti-spam features for other things.
Problem with DKIM as a hard evidence is that it’s not designed to be used like that and fails to provide proof beyond the fact that ”this email was sent from this specific server”.
As a server admin I have ability to send valid DKIM signed email from your address should it reside on my server.
This makes DKIM a middle ground solution. It does not provide strong end user centric cryptographic guarantee of the message authenticity which makes it un-usable as an actual replacement of mail signing where hard security is needed. While it does enough to do harm as the author suggested.
I fail to see how enabling attackers to forge emails is a help. Sure, the signature is from a now-public key. But this seems to be a technical solution to a human problem. If I want to blackmail a Presidential candidate, or pressure a person with access to classified information, I can just use one of those old keys to forge an email, then threaten to release it. People will use the fact of a valid signature as proof that the email is genuine. Unless you can prove that the email does NOT date from when those keys were still private, you have no way to debunk that claim. Sure, they can just release an email with no DKIM sig, but that lack will raise suspicion of forgery.
If the private key is released, then any email signed with that key can be denied as a forgery. Time stamps can be forged along with everything else. Once a particular key is released, it ceases to be a proof of anything.
> Modern DKIM deployments are problematic because they incentivize a specific kind of crime: theft of private emails for use in public blackmail and extortion campaigns.
I’m not buying this entire argument because you’ve still managed convince me that this behavior is worth disincentivizing. I know it’s a flawed analogy, but this is like saying you shouldn’t put your money in a bank because that just incentivizes bank robbers to rob banks.
Yes, sure, of course it does, but that does not outweigh the benefits. I think that’s also true here. Non-repudiation may be an unintended consequence, but it is also useful. Hackers are going to try to steal confidential e-mails regardless of whether they could have been forged or not; the benefit of us being able to tell whether an e-mail did or did not come from a politician’s account outweighs that.
The larger argument I believe is that this is an unintended consequence of DKIM that users of email services are not aware of, did not ask for, and are never given an opportunity to opt-out of. It doesn’t affect malicious actors as they are not tying their real identities to burner accounts anyway, this is only a useful method of authenticating emails of unsuspecting users with an otherwise legitimate right to privacy.
I think I agree with Steve Davis’ earlier post. This is an unintended consequence, that users almost certainly don’t realize they’re invoking.
If one intends an email to be evidence, down in stone for the ages, provable, then that should be an explicit action, not an accident. It is, after all, my email, not the news media’s, and not the government’s.
I think I’ll investigate doing this on my own server.
There’s no evidence DKIM has increased the theft of emails or the frequency of their publication. What you are proposing would only provide a hiding place for scoundrels. This ongoing authentication however has become invaluable to the public, as it also protects the public AGAINST blackmail by credible forgery. If Google hypothetically were to publish the private keys, we would then conversely see the advent of cryptographically signed forgeries – which would be deniable as you say, yes, but much less plausibly so than before.
Anyone can still sign their emails separately. The difference is that that is done intentionally for that purpose, whereas with DKIM it is an accidental, and unwanted, byproduct.
That is not a response to my points.
Accidental != unwanted. As one of the authors, I happen to think it was a nice accident. There are plenty of cases with enterprise where it is a very useful feature, like for example employee misconduct (or not).
If you always sign your emails, then any email without a signature would be assumed to be fake. If a private key is released, then anyone can forge emails and you would have to be an idiot to believe an email signed with a released private key is more likely real than one without an signature.
A faked sigure is nonetheless a signature. There are plenty of idiots in this world, and it’s very costly to hire technically savvy lawyers to defend against them. I might rather give in to extortion than be dragged through court, depending on the the demand.
Wouldn’t having your MUA delete the DKIM headers after verifying them provide an effective user opt-out, at least against future compromise?
That works for the recipient but doesn’t guarantee protection of the sender since the sender has no control over whether or not the MUA cleans the headers. Still, it is an excellent idea and the major mail service providers should be encouraged to do so.
Lets assume that DKIM as you stated is misused. But your solution is also flawed. If you want short term identification of the origin server, than the receiving server, upon mail receive, should just contact origin server and ask with cryptographic email hash – does it came from you? There’s no need for dkim, external keys etc. Just as simple two phase commit between origin and recipient server.
Adam, email usually travels through many hops. The origin and destination server in that case don’t talk to each other directly. It is usually pretty quick, but it is still a store and forward system that avoids requiring the endpoint servers to both be online at the same time.
Hi,
reading your blog post gives the impression that DKIM gives a proof about the content of an email (your write “the signature covers the content and most of the headers”). This is not true.
DKIM does not sign the content at all, it signs _some_ headers of an email (not even most). So it can be used to proof that A has send a message to B, and depending on how DKIM is configured for a domain also the subject line of the email (I would assume most of the time the subject header-line is included), but it tells/proofs absolutely nothing about the content of the email.
Right now the gmail DKIM signature allows to proof the following headers “h=mime-version:references:in-reply-to:from:date:message-id:subject:to;”, and that’s it (the content of the email is not signed).
Yes, some of the meta-information may already be enough to blackmail someone, and I do not object to the generic idea of your request, but you can not proof at all that the content / body of an email is the one the sender wrote. You can replace the entire text of the sender without modifying the header, and the DKIM signature will validate.
Bye,
Alexander.
The whole body is also part of the signature actually, if you check on a DKIM signature header, you’ll see a “bh=” field, this is a hash of the body, that hash is included on the “h=” headers to sign.
Meaning the “b=” (which is the signature), has also signed the “bh=” part.
to sum up, all the headers listed on the “h=” field AND the “bh=” hash (hash of the body) are used to generate the signature you can find on “b=”
“Modern DKIM deployments are problematic because they incentivize a specific kind of crime: theft of private emails for use in public blackmail and extortion campaigns”
There are these of us that do not believe that leaking or copying data is theft (nor that it should be a crime). This argument reminds me of the one that RIAA uses regarding “stolen” music.
“An accident of the past few years is that this feature has been used primarily by political actors working in a manner that many people find agreeable — either because it suits a partisan preference, or because the people who got “caught” sort of deserved it.”
Or because it enables transparency. Since you felt like accusing all of these who disagree with you, consider the following, given that you decided to post this right after the Biden DKIM thing one could say that you are saying this because it happened to your prefered candidate.
“This is an amazing resource for journalists, hackers, and blackmailers. But it doesn’t benefit you.”
It benefits me because it allows for transparency. It also allows me to prove to the whole world that I indeed received a message by someone (could be a contract, a promise, or a threat). There is another benefit, normally anyone can take a screenshot of their favourite email client using a forged email and claim that you sent them that, usually people will believe them (this happens more often with sms, discord, etc screenshots). DKIM gives you the ability to say “if you don’t show the signature then you are lying” – it gives you the ability to reliably declare an email as fake, something that you lose if we go by your suggestion.
If you want to disencourage leaks by 3rd parties the best solution is to encrypt the messages, that way you keep the ability to prove to the world that you received a message and at the same time a leaker is not able to use said email.
“For better or for worse, the DKIM authenticity stamp has been widely used by the press”
It has but the vast majority of people would either believe or reject what the emails said regardless of DKIM. Just go and look at the online discussions about the Biden email, the ones that believe it and the ones that reject it both don’t even know what cryptography is and if you try to explain to them they will leash out on you because it contradicts their dogma.
Matt, Dan Bernstein pointed out this issue way back in 2001:
https://groups.google.com/g/sci.crypt/c/73yb5a9pz2Y/m/LNgRO7IYXOwJ
uh, that was 3 years before DKIM, or its precursors DK and IIM.
Marisa, re: “There are these of us that do not believe that leaking or copying data is theft (nor that it should be a crime). This argument reminds me of the one that RIAA uses regarding “stolen” music.”
Those two things are not similar at all. The RIAA is mostly concerned with data (musical bits) that is already public and can be legally obtained by anyone by paying a few bucks for the recording at a music store. Their posturing about theft relates to people copying those bits themselves instead of paying the few bucks for them. Of course they are fighting a losing battle.
It’s pretty bizarre, though, to conflate published music with private correspondence, which can be literally (not figuratively) stolen, as in the case of Watergate-related burglary of Daniel Ellsberg’s psychiatrist’s office to get his medical records for purposes of discrediting him. The records were in a locked filing cabinet that the burglars forced their way into. The mangled up filing cabinet is now on display at the Smithsonian and you can see a picture of it in Ellsberg’s Wikipedia biography. If carrying out a covert burglary to get documents by breaking into a locked cabinet is not theft, I’d like to know whether the word theft means anything at all. Ellsberg himself leaked the Pentagon papers expecting to go to jail for doing so.
The view that copying or leaking this type of data should not be a crime basically says there should be no such thing as privacy. That’s logically consistent, I suppose, but it’s a little bit surprising to find here on a cryptography blog. Most of us into cryptography got into it because we believe in privacy. Here we’ve got an email infrastructure acting in a way that can make involuntary disclosure of private data more damaging than it might otherwise be. How can we think that is a good thing, even if leads to a good outcome in some cases? Should we let the police search people on the street all day long, because they might catch an occasional criminal that way? Treating everyone’s private correspondence as presumptively criminal (by adding these authentication marks), if done by choice rather than accident, is closer to “police state” than “open society”.
And yes, some people do believe the contents of forged documents (think of the Turner diaries, the Protocols of Zion, etc). Sane people generally consider those believers to be stupid or crazy or at least gullible. That’s why the authentication in the emails Matt described actually matters. I’d support a public interest defense for leaks like Ellsberg and Snowden did, but that’s way short of adding obscure technical machinery to enhance the potential leak impact of every email that anyone sends to anyone else. It’s pretty clear to me that DKIM’s designers didn’t think about this or underestimated its significance. Infosec people (hopefully) want to mitigate damage from security failures rather than increase it, just like doctors (hopefully) want to cure sick people rather than making them sicker.
Re: “Those two things are not similar at all.”
I thought Marisa’s reference to the RIAA position is useful in that it refutes a similar underlying moral premise by the author with an appeal to more abstract questions.
“Their posturing about theft relates to people copying those bits themselves instead of paying the few bucks for them”
And ‘theft’ in this article relates to people copying certain bits themselves instead of the author willingly giving them, this is pretty much what RIAA defines theft as. It comes from the belief that humans can ‘own’ certain numbers and deny from others the right to copy/use/distribute/etc said numbers.
“as in the case of Watergate-related …”
The example that you gave is indeed theft because the original papers were literally stolen. This topic however is about emails, not physical papers.
“The view that copying or leaking this type of data should not be a crime basically says there should be no such thing as privacy”
Or it means that there should be both privacy and individual rights.
“Here we’ve got an email infrastructure acting in a way that can make involuntary disclosure of private data more damaging than it might otherwise be.”
The old boogeymen that were used to discourage the use of cryptography were pedophiles and terrorists but now it’s leakers. I consider the ability to verify the authenticity of a message (and especially the ability for the receiver to prove to others that the message is authentic) more important than this newfound boogeyman.
“Should we let the police search people on the street all day long, because they might catch an occasional criminal that way? Treating everyone’s private correspondence as presumptively criminal (by adding these authentication marks), if done by choice rather than accident, is closer to “police state” than “open society”
Oh please, DKIM does nothing like that. It is more like this: you ask Bob to tell $message to Alice, now I go to Bob and ask “Hey, did my pal Paul request that you to tell $message to Alice?” And he responds with “haha yes, indeed”. If anything denying them that right is closer to a police state (see gag orders).
“And yes, some people do believe the contents of forged documents (think of the Turner diaries, the Protocols of Zion, etc). Sane people generally consider those believers to be stupid or crazy or at least gullible.”
I am not talking about forged documents necessarily but rather of documents (or screenshots) which can’t be verified. These are everywhere and most people do believe them (most of them are also true). The ones that you mentioned are just some cherry-picked examples.
We didn’t consider it because submission authentication was pretty rare at the time. And I guarantee you that even if we did, nobody would have wanted to roll around in that tar pit any time soon for a problem that was only abstract at that point. Frankly I find all of this hand wringing about non-repudiation way overblown. Even without DKIM, it wouldn’t take a lot of effort to create a preponderance of evidence, if not beyond a reasonable doubt just from the back and forth, server identification, etc for the email in question. the internet is still forever with or without DKIM.
As one of the IM’s in DKIM, you are correct that we didn’t consider non-repudiation at the time we were working on it, though Stephen Farrell once mentioned something in passing about publishing keys as a way to invalidate them. It’s not correct to say that it’s only been recent that this “problem” came to light. I figured this out probably a decade ago as it became clear that most providers were then requiring submission authentication (which was spotty at best when we first started working on this in 2004) and that you can form a chain of custody that is pretty airtight. I always thought that was pretty cool, and I still do. my main question at the time was whether it would ever get invoked because it’s pretty geeky. I had no idea it was used with wikileaks.
I find the notion that publishing keys as a means of dissuading email hacks to be pretty tenuous. Do you have any proof that the wikileaks burglars had a clue that even DKIM existed? Surely Rudy didn’t. But there is a flip side to this: non-repudiation means that I can prove that somebody sent me something that puts a lie to their claim that they didn’t send it, or many other uses like, say, proving that you were working when somebody claims you were (yes, this is strangely specific).
So while it’s ok to say that we didn’t consider it, it’s not right that we considered it an anti-goal either. I think it’s a nice unexpected perk. I don’t know what Jim or Mark think about it. The one thing I think we’d all agree on is that the issue should be explored carefully as the protocol of publishing keys is pretty trivial: just store the private key in the selector. But there is a mountain of BCP there too because what might apply to an email provider doesn’t necessarily apply to enterprise, etc.
What about removing these headers as soon as possible during the receive process, and not to store them?