Ok Google: please publish your DKIM secret keys

It seems to me that especially when an elected official has something they don't want others to know about that it should be public knowledge.

After all an efficient marketplace only is efficient if all actors have access to as much information as possible.

EDIT: As a follow up, several people point out that it could happen to me or a family member, but this seems even further reason to have DKIM so that if someone attempts to blackmail me based on the contents of my email, checking the DKIM signature makes it even easier to disprove a bad blackmail attempt.

That specific e-mail does not have DKIM signature (maybe because it was sent his own gmail address? or to an gmail address in general?).

I am aware that even if they publish the DKIM secrets, these e-mail will not lose any value since these e-mails was posted before the secrets.

But I think using e-mails as evidence should be a thing in general. As you could receive them to your personal e-mail server and want to authenticate and use it on a court, even years after. If they publish the keys, it would not be possible as you could be the one who forged the e-mail as it were received from somebody else and has been put to your IMAP server manually.

In messaging cryptography, non-repudiability has for almost 2 decades been considered a vulnerability, not a feature. The OTR protocol[1] takes the step of publishing its used MAC keys --- it releases private key material! --- to ensure that random people can forge messages once participants have authenticated them. Signal came up with a novel deniable AKE[1] that is one of the more famous parts of the protocol; by design, you can forge a Signal conversation from someone's private key even if you've never talked to them before.†

When you think about it in the abstract, it's easy to understand what's going on, even if you don't take the time to read the OTR paper. Once counterparties have authenticated each others messages, authentication has served its purpose. To allow a stranger to authenticate a messages is to concede information to them, and avoiding concessions is the point of messaging cryptography.

If you believe non-repudiable messages are necessary for public policy, it's hard for me to understand how you'd support the rest of secure messaging. Most secure messengers also have "disappearing messages", which have an even more powerful impact on the public's ability to read your (or some disfavored other's) messages. In fact, keeping the public from reading stuff is... kind of the obvious point?

Maybe it's just email, and the belief that email should not just be insecure, but be deliberately insecure? But, you all get how weird it is for me to read that after getting yelled at for writing a blog post about avoiding secure email, right? 547 comments[3]! Many of them very angry!

[1]: https://otr.cypherpunks.ca/otr-wpes.pdf

[2]: https://signal.org/blog/simplifying-otr-deniability/

[3]: https://news.ycombinator.com/item?id=22368888

† I'm always looking for this triple-DH blog post and never able to find it, because it doesn't contai the word "triple", and it never occurs to me to search for "deniable", only "repudiability" (which also doesn't occur in the blog post) so I guess I can thank this thread for fixing my bookmark.

>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.

No, it doesn't. It simply offers an assurance that, at around the time of sending, a given email was mostly likely sent from the server that signed it. It can't prove _anything_ about who actually sent it, because it can't guarantee the ownership of the email account.

>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.

There's no _better_ there -- only for worse. It would be better to dispute the validity of using DKIM for non-repudiation of emails than to propagate the lie and ask server operators to publish their expired secret keys.

1) it seems unlikely this cryptographic proof is needed (he acknowledges this criticism in the post), and

2) what seems more likely to me is that politicians would intentionally _not_ opt in to any alternate solution and use that deniability for their own advantage. (Also as an alternate he proposes GPG, which I know Matt knows is laughable).

Calling for the ability to remove it during the years 2016-2020 in order to "protect politicians from blackmail" is not only of deeply questionable value but of suspect motivation. Who is the author interested in protecting?

The comments here on Hacker News seem to have tripped on the examples given (keywords: politicians, journalists) and turned this into the more generic and politically loaded discussion whether it's desirable to "cryptographically verify" what politicians write.

But that's not the point! The point is that DKIM is technically not designed for this use case and the way people misuse DKIM for this unintended purpose is highly problematic from a cryptographic and engineering perspective.

I think the best way to think of DKIM is that it's a "cryptographic protocol" in the sense that git is a "cryptographic protocol" because it uses SHA1. If you think "PGP" (not the best example :-)) or "Telegram" you have the wrong idea: DKIM is a bunch of cryptographic primitives haphazardly bolted on email to solve a specific problem. It's not good cryptographic design because good cryptographic design anticipates unintended usecases and deal with them appropriately.

1) Read the DKIM RFC.

First of all the only field that it's required to sign is the From: header (see RFC, section 5.4). So you could still forge an email but have it pass a DKIM signature check.

If people believe that DKIM "cryptographically signs" e-mails in the sense of PGP, then that's a problem, because that's not true. A DKIM signed email doesn't actually say anything: you have to look at the signature which part of the message are signed, which is not standardized.

So you could have this situation when people, like journalists or even people on Hacker News, think a forged email is valid because it has a valid DKIM signature (but the signature is over the From: header only). E-mail is complicated as it is without having to explain to people who have binary classified an email as "forgery" or "not forgery" based on a specific combination of email-headers and DKIM signature specification. Let's not do that.

2) Look at what mail providers actually do with their DKIM keys.

For legacy reasons due to DNS providers and length of TXT records, many large internet providers use DKIM keys that are 1024 bit RSA.

Already 10 years ago, most standard bodies started to recommend against the use of 1024 bit RSA. It's deprecated. Like MD5-deprecated.

The fact that many service providers use the same key for all emails for all customers and reuse that key for years, increasing the likelihood of the key being leaked, is another case against trusting DKIM for this purpose.

As far as I can tell, people who need repudiation are already using apps that have repudiation (eg Signal), because they know they are in a vulnerable position. The people who need repudiation already have it. So far we have seen DKIM authentication used against individuals in positions of power. With things as they are, cryptography is leveling the playing field by empowering the vulnerable while holding those in power responsible. If this situation or balance were to change perhaps it would make sense to rethink DKIM non-repudiation. I understand this is an opinionated/political take on cryptography that not everyone would share.

I've used Google's DKIM signatures to timestamp call recordings for years by putting a sha256 of the attached recording in the subject, so "literally no security purpose" isn't true!

(though I should probably go through and timestamp those signatures right now them using another method, just in case this guy's idea gains any traction)

1) DKIM doesn't protect the To: header in any reasonable way (its not really designed to). i.e. it protects it in the sense that the original email had that as the To: header, but this is easy to forge as the To: header is not used by SMTP in delivery (think Bcc). i.e. its easy to write emails that are To: <some address> that are never attempted to be delivered to said address.

2) DKIM (even on gmail) doesn't quite protect the From: header as one would expect. Yes, gmail in general makes it difficult to spoof the email in the From header (it will replace it with your own if you try in the general case), but there's a huge but, if you gave gmail itself access to use that e-mail. i.e. I can be compsciphd@gmail.com but if billgates@gmail.com was convinced to allow me access to send emails as billgates@gmail.com (either via cooperation or a technical or sociological hack) then i can do that without having access to the account. and this permission is permanent. as far as I can tell, it irrevocable and to other gmail users there is no indication that other accounts have this permission for your email.

so what do we learn

1) can't 100% trust DKIM to believe who an email was sent to unless you actually retrieved it out of said user's email spool 2) can't 100% trust DKIM to believe who actually sent an email (even on gmail)

now, do I think DKIM gives anywhere close to 0% trust. No, I think its much closer to 100 than 0, but one has to understand the limitations and most people who discuss it, don't seem to understand them.

the threat is a hack playing a very long game. If one doesn't view that long game hack threat as serious, then its close enough to 100% (especially if gmail rotates their keys even without making the private part public), but if a long game hack threat is a serious thing, then it drops.

Two questions:

Have there ever been any Gmail design decisions, e.g., default settings, where users were consulted first?

I was recenty informed by another HN commenter that "99% of users" are "not qualified to have opinions" on something like MacOS behaviour,[FN1] or in this case Gmail behaviour. If this is true, should "99%" of users be given the choice not to use DKIM if they are "not qualified" to have an opinion on DKIM?

1. https://news.ycombinator.com/item?id=25100342

This is true with the added proviso that, by "us", he means "the guilty". The rest are protected, on the contrary, to this very particular form of these crimes.

What if someone realizes that Google uses a broken cryptographically secure pseudorandom number generator (CSPRNG) à la Debian ? Unlikely but the risks exists, so not going to happen in my opinion.

Consider this excerpt from the blog post:

> 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.

The author seems to be arguing that if after a certain point it becomes impossible to verify whether an email was genuine or not, that would somehow be a good thing.

This reasoning seems harmful to me. It's incredible that the author treats this moral argument as self evident. Let me state my objections clearly.

1. The truthfulness and reliability of the historical record is important. The fact that politicians are protected from blackmail when they write incriminating emails is utterly insignificant by comparison. Is the principle being defended that protecting politicians from blackmail is stronger than a public interest in having a historical record?

2. Making historical emails impossible to authenticate after a certain period of time makes it more difficult to prosecute crimes. It helps criminals, the very thing the author claims to be trying to avoid. If a politician, or anyone for that matter, sends an incriminating email which is evidence of the intent to commit a crime, why on earth would you want to make it easier to cover your tracks?

Seriously, can someone present a moral argument for why this should be adopted? It seems only harmful to me.

Unless you're debugging something those headers seem irrelevant anyway, and they bloat the messages very much. (often times they are 3-4x the size of actual email)

To make this work you need to claim a forgery when you know that no such forgery occurred. So you explicitly or implicitly have to accuse someone of a serious crime/offence they did not commit. Most people have a greater sense of honour than that. Those that don't would still have to fear getting caught.

If someone actually does forge a message using the old private keys provided by Google then you would have to fight the assumption that you were using the system as it was designed. Everyone would just assume you said it and are now using the possibility of forgery to lie about having said it.

You can always claim a forgery anyway should you decide to do that. Perhaps someone got access to Google's relatively poorly guarded DKIM private key. How would you know? You are probably not making a specific claim anyway.

-- In the interest of users (will most probably never happen), all incoming emails should be ignored and dismissed unless the recipient has explicitly specified that it accepts email sent from a given email address. Wouldn't this give the power back to the users?

* emails between major email providers have this lingering semi-authenticity indicator that authors didn't explicitly choose

* to the extent the providers keep their DKIM keys non-public, only those providers (or those who exfiltrate such keys) can forge old emails

Both of these have problems if considered from 1st principles:

* Users should be able to control if they're creating non-repudiable messages.

* No one, not even Google, should have the power to create authentic-seeming forgeries.

This article's author, Matthew Green, suggests rapid expiration & disclosure of DKIM keys to narrow the window of time the user is subject to a non-repudiation they didn't choose. (Green here only specifically requests disclosure of years-old keys to invalidate older message archives, but conceivably a rigorous expiration-and-disclosure schedule could be chosen to limit the risk to weeks or days.)

And via public disclosure, Green intends to indirectly address the risk of privileged parties forging emails, by giving everyone the same power-to-forge older emails - so no particular forgery can be too convincing.

But these new defaults are nearly as ad-hoc – reactive without conscious design – as the DKIM problem they purport to solve.

Many would prefer that their emails, or at least some of them, be non-repudiable for a while or indefinitely. Many recipients would like to maintain their own private authenticity records – which as Green notes, can be bootstrapped into existence (even with rapid-expiring DKIM keys) by secure-timestamping messages & current DKIM keys at the time they're received.

(To the extent Google & other providers have internally-trusted tamper-proof logs, they may already have de facto secure timestamping happening on all inbound/outbound email. Thus any amount of DKIM key fouling wouldn't stop their unique internal ability to authenticate older messages, for their own forensic or political purposes.)

I'd prefer users be given some visibility into, and choice over, how much durable authentication is added to their email messages – before adopting either Green's quick fix (publish old keys ASAP), or defaulting all users to his potential longer-term solution of explicitly "non-attributable email" (per his KeyForge paper or other schemes).

If a hacker were to retrieve some emails before the DKIM key was made public, they could then sign their hacked emails with their own timestamped signature, proving that they are in fact authentic (since the signed timestamp shows that they were retrieved before the DKIM key was released).

Therefore, by rotating the DKIM keys "every few weeks" you are giving the would-be hackers a deadline to retrieve the target emails - a few weeks - which could lead to hackers preemptively hacking as many possibly useful accounts as possible (not just the ones they know they want at a given moment), every few weeks.

(The merits of OP's argument notwithstanding)

In the case of Podesta, the emails were stolen from his gmail account. If the headers weren't there, the messages would have been unverifiable.

https://www.onebigfluke.com/2013/06/bootstrapping-webfinger-...

(I suppose you could just re-opt into webfistbump every time your email provider is about to publish their DKIM key)

That said, I think this would be problematic on some levels not being considered. A good part of the world's email infrastructure is decentralized, and doesn't run on providers who update software well and often. If Google were to publish their keys after rotation, a new class of attacks could emerge where attackers could successfully forge authentic emails from Google that would look secure to an outdated provider. Nigerian prince 2.0 if you will.

Decentralization is one of email's biggest strengths. I agree with the premise here, but I don't think the solution is to publish keys. Perhaps moving to a protocol that explicitly provides non-repudiation while keeping backwards compatibility would work.

Sounds suspiciously like somebody's thinking ahead on how to plausibly deny some yet-to-be-leaked emails.

I think it's kind of unfortunate that there are many people that suddenly care when its powerful people or their families that are getting caught out by DKIM, these aren't the people who need protection from it the most. No one would even care if the Hunter Biden related emails passed DKIM except for the widespread allegation that they were fake, and no one still cares because conversation about them passing DKIM is widely suppressed (including on HN, unfortunately, where a post about it was immediately flagged). Oh well, I suppose it's like when the ACLU used to defend awful speech for the sake of defending free speech because those were the cases available which could make an impact.

Unfortunately publishing DKIM secret keys only goes so far towards avoiding accidental non-repudiation: Recipients can cryptographically timestamp the signatures before the keys are published. ... and doing so already makes sense independent of DKIM. In fact, one of the ways that the public was able to prove that the outdated google DKIM key was a real key was that we were able to find cryptographically timestampped google signed emails from back when that key was still in use.

Better than key publication is to avoid having a non-repudiateable stamp to begin with. This is much easier in the context of end-to-end two-party interactive protocols, but I believe is still possible for multiparty protocols.

The analog for DKIM wouldn't work so well unfortunately, because DKIM isn't end to end. E.g. DKIM could be changed so that the signature demonstrated that either the sending server or the recipient server signed the message-- this would be just as good for anti-spam, but really wouldn't improve the non-repudiation in most cases. Contrast that with applying the same approach to end-to-end messaging, where it gives you pretty strong non-repudiation.

so what's the point?

But someone could threaten to speak to your insurer about a medical condition mentioned in an email.

Perhaps a simple timestamped based appendage can be added for the sake of email client authentication. In other words reject the email if the signature is older than a few hours/minutes.

Email servers get hacked all the time, right? A disgusting amount. Its almost like security is really difficult; in fact, its difficult to secure both the emails and the DKIM private keys. They're usually on the same server, after all.

If a DKIM private key gets hacked, and the world relies on DKIM to provide non-repudiation in the verification of email leaks, then a hacker who obtains someone's DKIM private key could forge an email to contain any content they want, sign it with that private key, then leak that. The world says "its DKIM validated, Trump really did kill a litter of puppies twelve years ago", Trump tries to say "no, my email server was hacked, i never did that but they got my DKIM key" and who the hell would believe him? The headlines have already been written, and the argument against it is some crazy technical terminology a hundredth a percent of the population actually understands?

Ok, well, maybe you should rotate DKIM keys. Not necessarily make the private portion public, but at least rotate them and totally destroy the old private keys. But, again, if an email server is misconfigured enough to leak data, then its likely the admin is incompetent enough to also not be rotating keys. Moreover, unauthorized access to a server could happen over a period of years, during which hackers collect the rotated DKIM private keys while letting the admins think they're being deleted correctly.

The problem here isn't really DKIM; its the public's perception of what it was designed for. Technologists invented something, journalists discovered it, read a wikipedia article, and thought "woah we could use X for Y". So, I think it makes sense that we need a big name like Google to come out and say "Stop, this is not what this was designed for, it has major limitations in being used for that, and we're talking about real-world consequences like ruining potentially innocent peoples' lives."

I contacted Bruce Schneier a few days back and he claimed that Robert Graham is lying and that this was fabricated, in addition that one is unable to establish the integrity and authenticity of a message by using DKIM.

I personally think that if Bruce Schneier is wrong and one is indeed able to establish the integrity and authenticity of a message by using DKIM then it is useful for the one receiving the message to prove to others that the mail indeed came the one who sent them the message. Consider a harassing email or a promise for example.

The Hunter Biden email is a good example.

I initially thought it was a garbage tabloid drop, but once I read Rob Graham's analysis, it felt very refreshing to have a real nugget of truth based on math. While the context of that content is up for debate, the truth was essentially undeniable (unless you subscribe to the 2016 private key being stolen).

We need nuggets of truth.

What right does Google have to force this onto us. If I want it, I'll chose it.

The idea I consented because the information was there somewhere and I should have know the complexities is as BS as hidden terms and conditions.

What annoys me is if you're pro fascism and want to force tracking onto people, just say it. But stupidity about how this isn't totalitarian is unforgivable. I have a right not to be tracked.

The only one I can imagine is that Google wants to get some positive PR out of it. Other than that it seems to me like Google will just ignore this as they ignore anything else they don't see as in their benefit to exert effort on.

P.S. This brought back memories. To anyone unaware of this, read about Pizzagate. You'll find that it has supposedly been debunked as a "conspiracy theory"... except for the emails which we know are legit.

Basically anybody could use those signing keys to fake email from a politician or celebrity. Imagine the headlines “Celebrity X account hacked, here are the emails, cryptographically verified by Google”

Of course, informed people will know that anybody could have faked them, but I would guess normal people would be fooled. In addition, there is no way to say the emails are definitely fake. At least now, we can tell between actual leaked emails and fake emails.

An alternative would be for email servers to strip the DKIM headers on inbound emails after recording that the email was validated. The email stored at rest then no longer provides non-repudation. Nothing is stopping you doing this today.