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.
A counter to the non-repudiation of old emails is the fact that people who own their own mail servers can rotate their DKIM keys. So it's already possible for e.g politicians to have their email set up in such a way that they're insulated from leaks.
The argument here is more that customers of gmail and other email services are not offered repudiation as a feature.
> That's strong evidence that the email is authentic!
So I run my own email server for family (mostly) but a couple of friends. As the GP points out, the DKIM keys do not identify the user and in particular I can produce a validly signed email for any user of any of the domains my server hosts. Only CMS oblique S/MIME would provide non-repudiation in the cryptographic sense, and only meet e.g. eIDAS requirements if stored on a hardware token (i.e. in the EU, if I sign a PDF with the USB token I have, it is a "qualified signature" and it can be interpreted as legally binding).
On the other hand, there's a question as to what extent courts would understand the distinction between a valid and invalid/no DKIM signature. I guess what I'm saying is if it came down to a contractual dispute, "strong evidence" would not be good enough. If it came down to "this person organised a protest and that's a crime" I think even invalid DKIM would be fine. From what I've seen of court proceedings, mostly stuff shared here and so US stuff and not my native jurisdiction, but I have yet to see anyone cast doubt on an email's provenance based on DKIM. I'm going to go out on a limb and say in strongly democratic jurisdictions an email recovered from a server in someone else's inbox will likely be treated as valid unless there is something like an unusual sender IP to cast doubt on it. So "strong evidence of authenticity" probably won't come from DKIM.
In jurisdictions where protesting means you disappear, I doubt "check the DKIM keys!!!" is going to help - at least in part the police/courts might not be so worried about whether you are guilty or not.
Agree completely with the sibling comment that e-mail isn't suitable for secure messaging.
I can imagine why the author could maybe want plausible deniability against potentially leaked or forged emails, but I definitely see DKIM and non-repudiation a feature. I suppose the caveat is that if DKIM private keys were stolen, fraudulent emails could be convincingly generated, but this isn't a normal concern for users of the big hosted webmail services.
The problem with the author's paper is that his assumption (and that of, apparently, media organizations, Wikileaks, and others) of DKIM "ensuring non-repudiation of emails" is simply wrong.
>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.
The argument is that the system as a whole shouldn't be set up in a way to provide (possible, limited) non-repudiation, similar to how postal mail (at least in the US) doesn't provide non-repudiation. It is not something that most people individually would have a say in how it is set up. Publishing expired DKIM keys wouldn't let you claim to the recipient that the message was forged but would make it harder to convince third parties in some contexts that the message is likely to be authentic.
The advantage of deniability is that someone who manages to get one email of yours by any means can't prove to the world that you sent it, which can be an issue with things that are socially considered unfavorable as well as unsympathetic situations like corrupt politicians. There are disadvantages relating to harassment and corruption.
The article doesn't mention it but trusted timestamping during the validity of the DKIM key (plus as always having a copy of the public key) preserves the (limited) non-repudiation. Forwarding during the DKIM key validity could potentially work as a reliable timestamp depending on the details of the forwarding.
>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.
For context, this idea of publishing the secrets has come up again recently after DKIM was used to prove the authenticity of the “smoking gun” Hunter Biden email. [1]
More generally, non-repudiation is a great feature if that’s what you’re going for. Often times it’s not actually what you needed at the time, but gets thrown in anyway because it’s harder to design a signing protocol without that property than with it.
So in the sense that non-repudiation isn’t a core requirement of DKIM you’d like to have the crypto algorithm which meets just the DKIM requirement and no more — yes, this email definitely came from an authorized server and hasn’t been tampered with, but without inherently proving that the email is not a forgery years later.
On the other hand, DKIM having this property is actually extremely useful and nice to have a lot of the time, not the least of which in the Hunter Biden case, or for the purpose of authenticating any particular historical email.
> Non-repudiation over time is a truly powerful property of DKIM'd email for a great many uses outside of blackmail.
This. Publishing the DKIM keys would be a huge loss for email archivists and historians in general. E.g. a couple weeks ago Donald Knuth published all of the emails he's sent and received over the last 20+ years of his career[1], without DKIM how would we know that they are authentic?
We've backed into a particular default, more via path-dependencies than conscious choice, that:
* 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 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.
I’d love to hear more about this. If I send an email from the Gmail UI, at a high level, how does DKIM ensure that Google can’t deliver the message with a different FROM header?
And, to clarify: your answer can’t involve trust/reputation because, well, both you and the person you quoted chose to use the word “prove”. Something being inadvisable and unlikely (Google forging emails) does not prove the opposite thereof.
Has this kind of repudiation ever been tested in the real world? It's hard to imagine a court throwing out email evidence because it lacked a DKIM signature. And on a personal level seeing a chat transcript that had cryptographic non-repudiation would make me likely to believe it, but seeing one that lacked it would probably not weigh heavily in how I came to that determination.
Non-repudiation is of course a needed property for many systems, but it is not a property a system, especially an everyday messaging system like email, should have by accident - even "weak" non-repudiation such as DKIM. It is a violation of privacy. The suggestion the author makes of course doesn't completely get rid of it, but at least makes it time-limited.
I don't understand your point, content signature verification would have the same consequences that HTTPS for non-repudiation, no?
Also it's really different from DKIM: the problem with DKIM is that since the signature is part of the email itself, so unless the receiver bothers to strip it (why would they?) then it's stored forever in the metadata, even though arguably its use as an anti-spam feature stops being relevant once it's been delivered to the MUA. So basically every time you send an email through gmail you effectively also send a signature saying "I, Google, vouch that h4x0r@gmail.com did send this email" and the receiving end will keep this signature for as long as they keep the email.
HTTPS session keys however are not typically saved unless somebody goes out of their way to do it. As such it's a lot less likely to be used for blackmail in hindsight. In general people use archive.org to prove that some content used to exist in this scenario, not old HTTPS session dumps.
And like for DKIM the solution is fairly trivial if it's really an issue: every time you rotate your keys (which should be fairly frequent if you use something like letsencrypt) be sure to make the expired private keys available publicly to give you plausible deniability.
I have yet to hear a good argument against HTTPS everywhere honestly, it generally boils down to "but I don't want to do it" with some weak post-hoc justification for why it's bad.
Meanwhile, the IETF is speccing more messaging protocols with non-repudiation and HN users seem to be cheering that shortcoming along: https://news.ycombinator.com/item?id=25100316
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.
> Accidental non-repudiability can have negative consequences itself. For one, relying on the kind of poor man's non-repudiability that DKIM gives you leaves powerful central entities with the ability to forge email while convincing almost everyone that it is legitimate.
I fully agree.
> From reading everything that you wrote, I think that your thesis is that email, specifically, ought to be non-repudiable. That might be a worthwhile idea, but it should be presented as such at the forefront. If others agree that this is a valid and useful concept, then a non-repudiability mechanism could be added to email explicitly, just as DKIM was added. But don't use DKIM for this, since it is a poor substitute.
If the choice was between "DKIM for non-repudiability" and "a better mechanism for non-repudiability", of course I would support the better mechanism. But that's not the choice here. The proposal here is to remove this accidental, partial non-repudiability mechanism that currently exists, and replace it with nothing. That would leave the world worse off, not better. DKIM protects innocent people from being framed for saying horrible things, and DKIM protects innocent people from guilty people who do horrible things. And sure, sometimes DKIM might be used against innocent people in some way, but the balance seems heavily in favor of DKIM (from the perspective of innocent people).
> 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.
> 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.
Not on it's own, but it's a critical step in this chain:
1. DKIM verifies that a message was sent by Gmail.
2. We assume Gmail is careful with its keys.
3. We assume Gmail doesn't forge addresses.
4. Find evidence that links me to that address.
Most people will readily grant #2 and #3. Now we just need #4, which can be easy.
No, it's not cryptographically verified end-to-end, but it's good enough to convince a court or to convince a respectable news organization to run a story.
The gmail DKIM signatures are not a reliable verification that the contents of an email have not been modified. The algorithm and key length of the signatures used by gmail (sufficient for anti-spam) are cracked with an honestly trivial amount of hardware according to RSA in 2003 [1]. Since the premise here is that a state-backed adversary is involved, we can reasonably expect that the keys are compromised.
I wonder how well the non-repudiation would actually hold up in that scenario. If you self host your mail server, the attacker could possibly steal your private key and forge the emails. So you might actually have repudiation. Or does DKIM have a timestamp? If not the attacker can simply send an email from your laptop and get it signed by your mailserver. Thus another route for claiming repudiation.
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.
reply