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.
I did run a few months in no-DNS email mode without issues, but was 2-3 years ago. I know regulation and lawyers may be needed if significant conflicts happen with unreasonable system administrators.
It is critically important to keep the emails flowing independently from the DNS mafia/racket, like the web, but I guess we all very know that here on HN.
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...
But then you could just have a third key to use in place of the first for anything you think you might want to get out of later.
You could have a mechanism to prove two emails are signed with the same key, without revealing the public key (e.g. using a zero-knowledge technique like zk-SNARKs) - but that might then be functionally equivalent to just revealing the key in terms of non-repudiation anyway.
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.
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.
Link? From what I remember, the details in that case where handed over in cooperation. Was there anything actually denied? There was only the issue around retention/deletion of emails, but even that didn't include a tech proof AFAIK.
You can set identities in gmail from which you can send emails. If it weren't gmail but a mail server you hosted, it would be even more trivial. Neither of these have to do with SMTP authentication. Without significant other configuration the mail server does not care what Mail From: address you enter. This is how my classmates were able to get emails from the US president back in the day.
"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"
I've tried several times to do what I think is being claimed here and I'm struggling. For instance, telnet to a public mailserver I control, SMTP AUTH with an account with relay permissions, MAIL FROM so@so, RCPT TO my own Gmail, refused by GMail due to so@so's DMARC policy...
So I just tested it again (took a while as forgot needed the -crlf option in s_client)
So, gmail does rewrite the From: header (well it keeps the name, but replaces the email within the <brackets> and adds a X-Google-Original-From header), and as this story is about senders (not receivers), spoofing would be protected in that regard.
However, what I remember now, is that I was proving that it doesn't tell you anything if the person in the To: was actually sent the mail.
i.e. even though DKIM protects the "To:" and "From:" headers it has nothing to do with the Rcpt To: (i.e. think how BCC works). So DKIM doesn't prove that an email was actually sent to someone (even if its on their machine now), just that someone might have faked a scheme where they sent an email with a To in the headers to someone, but the RCPT TO was not that person. So, it get signed as such, but isn't true. And in the case of gmail, the only reason there's any form of protection on the From: header is because gmail enforces a level of protection outside of dkim.
So what I must have done back then, was send people emails that looked like they were meant for Hunter Biden to receive that had all the DKIM validation check out, but were obviously never sent to him. (with all that said, for someone to have actually done this to Hunter Biden, they would have had to be playing such a long game, it's almost inconceivable to me, I was just proving that DKIM doesn't actually tell you if the supposed recepient is actually the receipient when sent via gmail, but as others have noted, if the From: header in the email isn't as locked down as gmail (and I'm sure not all are) / one knows of an exploit in gmail to subvert the From header in place editing, then it doesn't even help with that).
anyways, I apologize for exaggeration in my original post, its wasn't quite accurate. I hope I cleared up any confusion I caused.
> So DKIM doesn't prove that an email was actually sent to someone (even if its on their machine now), just that someone might have faked a scheme where they sent an email with a To in the headers to someone, but the RCPT TO was not that person.
We find the DKIM headers on the recipient's copy of messages, and they confirm information about the authenticity of the sender, right?
So a malicious actor in league with Alice prepares a laptop which purports to be Bob's (but isn't).... and on it there are DKIM-signed messages "From: Alice <alice@example.com>" and apparently "To: Bob <bob@example.com>", except they didn't actually go anywhere near Bob because they were "RCPT TO: <someone_else>"?
Thinking about forging mail, in the case of senders who control their DKIM signing keys (me, for instance), if you have the sender's cooperation then you have access to their private DKIM key, can't you just sign any message you like?
No need for the messages you're forging and signing to go anywhere near any email clients or mailservers at all.
yes, for example, an insider at google could conceptually have forged a mail. just don't consider that probable. I think its more important to understand the limitations of what DKIM is telling us.
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.
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"?
They absolutely will assume something was fake if it's embarrassing and they think it can't be proved. Most of them don't know about DKIM signatures, though.
A lot of wikileaks mails were verified with DKIM, and as I recall some of the people sending them initially denied it.
Here is the tool the Associated Press uses to check DKIM signatures [1], and here is Wikileaks' page on DKIM [2].
DKIM is routinely used to verify emails in cases where the evidence chain back to the source is unclear. I was personally involved in a forensic effort to verify DKIM signatures on the Hunter Biden laptop [3].
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.
> 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.
The publication date of the DKIM record will be _after_ the email has been sent.
Obviously there is no real way to 'prove' the publication date of a DNS record, other than asking the DNS service provider for the logs maybe.
So IANAL, but I'd say the lack of provability of the publication date of the key makes it unsuitable for deniability. Just because the DKIM public key is currently public, does not prove in any way that it was already public when the email was sent.
> The publication date of the DKIM record will be _after_ the email has been sent.
Was that email even sent? Maybe it was forged after the key was leaked. This is what the author of the article is pointing out: The old private key being public, you can no longer rely on DKIM alone to prove anything about a document with a signature created with that key.
Deniability means an adversary can't prove you did X, not that you can prove you didn't do X.
So to check if the property holds, the question is not: can you prove the key was public when the email was sent, it is a) can the adversary prove when the email was sent, and b) can the adversary prove that the key was not public at that timestamp?
On a), the adversary cannot just rely on Date: headers if those headers are signed by a public key, and the private key is now public - someone faking an email could just back-date the Date header to a date when the private key was not available, and hence an argument by the adversary that 'the Date header says it was sent at timestamp TS1, and at TS1, the key wasn't public, so therefore the email can't be repudiated' is not sound.
If the recipient of the email cooperates (or anyone who gets access to the email before the private key is published), they could, for example, hash all their emails, and then hash the list of hashes on a regular basis, and put that hash in a busy public blockchain. That would provide an upper bound on the email send timestamp, and, combined with a well-defined private key publication timeframe, provide non-repudiation.
The point isn't establishing deniability, the point is undermining the authenticity argument (these are at least subtly different I think).
It isn't actually possible to prove that the key was secure at some point in time prior to publication, publication of the key moots that discussion, which is probably going to generally be socially favorable enough of the time to be the better thing to do.
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.
This is builtin with X.509 certificates having an expiration date, and also the ability to revoke them before expiration. Unless you have a cryptographic timestamp proving the signature was made before expiration or revocation, signatures stop proving authenticity once the certificate has expired/been revoked.
No, because people don't think like SSL libraries and there's a big difference between "you should trust this key" and "this key provides good enough evidence of authenticity to count as incriminating". To defeat the latter the key must be published.
Yeah, that simply won’t happen with keys in HSMs, where private keys reside more and more frequently nowadays, as they should for security reasons. They are specifically designed to make it impossible for the key to leak. In Europe for example, this is a prerequisite for signatures with legal value.
Which is fine if you don't want deniability, and probably desirable for legal signatures. But that doesn't make it something with no value. Parent poster was claiming it made no sense to want authenticity and then publish the keys. I'm just pointing out that there is a desirable property which uses that approach. And HSMs can be (and commonly are) configured to store keys which can leave the device, though setting a specific time lock is not something I think many support.
The majority of email comes from major email providers (think Google, Microsoft, etc). They certainly own HSMs.
Hence my statement that this scheme only really works for self-hosted solutions, because you won't be able to obtain the keys from third-party email providers.
If it's used for DKIM is another matter. You don't have only 1 mailserver with a HSM if you are this big. Having 1 HSM with the private key would create a massive bottleneck and SPOF. If they have a HSM for each server with the same private key, the key can obviously be extracted from the HSM, making publishing it possible.
That’s not necessarily true. You can cluster and replicate HSMs to provide scalability but it is common practice to forbid extraction of private key material. In many cases you can’t change that setting without a complete reset of the device.
Edit: to expand on this a bit. The clustering will involve exchanging key material in encrypted form between each HSM. But that exchange is typically protected and authenticated by keys that are themselves attested as having been created securely in hardware. You can’t just inject your own keys to mitm that connection.
It can be scalable if you’re prepared to chuck enough money at it. (Response time latencies are another matter, but that is somewhat less important in email). I have no experience at all of securing production mail servers, so whether they do this or not I don’t know and other replies here suggest they don’t use HSMs at all. If they do use HSMs then it’s not crazy to assume that they can’t easily publish old private keys, but if they don’t use HSMs then that is irrelevant.
The PKCS#11 standard, which is implemented by most HSMs defines two attributes that control this:
- Marking a key as “sensitive” means that the raw key material cannot be exported, except in encrypted (“wrapped”) form. Such an encrypted key can then be unwrapped to install it on another HSM. This key-wrapping facility is largely to allow backup or replication (but see below).
- Marking a key as “non-extractable” also means that it cannot be exported even in encrypted/wrapped form.
You generally configure a policy on the HSM to say that all private keys must be sensitive etc. It is pretty common (in my experience, dealing with banks primarily) to enable a policy that enforces all private keys to be sensitive and non-extractable. Proprietary mechanisms are then used to replication and backup of those keys (that effectively ignore those attributes/work at a lower level).
>As I understand it, it should be impossible to export a private key from an HSM.
This is my understanding too. But if you have several HSMs which should all have the same key (needed for DKIM) then there needs to be some sync/export/import mechanism.
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.
I don't think that's an accurate characterization. If you have an email with a DKIM signature, from Gmail or from a myriad of vendors, then either:
a. The email is authentic.
b. The service allows whoever administers the service to configure outgoing emails however they please.
c. There is a documented method by which the service allows you to override the sender address.
d. The service has risked its reputation to "forge" the signature.
The middle two options are extremely common in any business setting. Gmail supports both.
--
I am assuming, since your post does not appear to be agreeing with the parent comment, that when you say "authentic" you mean "sent or authorized by the individual named in the username field". If you mean "sent in a manner configured by some entity with authority on how the domain is used for sending email", then that is exactly the parent comment's point.
> 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.
Remember when Hans Reiser successfully destroyed all definitive forensic evidence of his murder of his ex and then got convicted anyway because nobody believed he was innocent then traded handing over her body for a lighter sentence?
Even if you could theoretically create a mathematically plausible doubt it doesn't matter if a judge and or jury doesn't believe it.
Also both Google and the recipient can attest the message hit the server prior to the key being published. You MAY be in a position where your email provider is in a different jurisdiction and not inclined to cooperate but if bob the witness already gave up your message won't he give up the timeline breaking any hope of repudiation?
So all hope of an upside is basically a pipe dream. Lets talk about the downside you can now sign crap with Googles already published key and lie about the timeline. You can have "experts" go on TV and lie about authentication. Since most people know less than nothing on the topic it sounds on its face believable.
Hans Reiser was convicted because there was much circumstantial evidence, he insisted to testify, his explanations were unlikely, and jurors thought he acted guilty. He said he threw away his car's passenger seat after his ex wife disappeared so he could sleep in the car. And removed the rear carpet to make a futon. But threw it away. And so on.
Criminal cases are not the only scenarios when authentication is relevant. Most email providers would not authenticate a message without a court order probably. And they may or may not retain sufficient information. A recipient whose messages were hacked would not want to authenticate the messages usually. A recipient who would benefit from disclosing a message the sender didn't want disclosed would benefit from forging a message usually.
Is it now not possible for people to go on TV and lie to people who know less than nothing about a topic?
Its easier if we can go say something half truthful like your blood was found at the scene even if the scene was a kitchen where you had regularly cooked and the blood was of indeterminate age than to make something up from whole cloth. The later is also legally actionable while the former may well not be.
The jurors heard where blood matching Nina Reiser's DNA was found. It was the entrance of the house where Hans lived after they separated and a sleeping bag cover in his car. Not the kitchen. They heard his claim she cooked there. They heard a witness admit bad technique meant the sample inside the house could have been Hans's blood mixed with other DNA from Nina. Saying the age couldn't be determined didn't help the prosecution. Reports at the time said it was the 1 piece of evidence the defense made reasonably doubtful.
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.
> 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.
> […] 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.
Proving something always comes with assumptions and caveats. Even if we're talking about proving something cryptographically, the underlying assumption is that crypto primitives are unbroken or that participants retain control of their keys.
In this context, DKIM definitely proves a user sent an email if you're willing to accept the assumption that the email provider is not arbitrarily sending emails that users did not write. This is perhaps not as strong a proof as if there were user specific (and user controlled) signing keys, although even then you're still making assumptions about the user's ability to control their keys, the software involved, etc. In the case of DKIM, it's certainly a much stronger proof that the user did indeed send an email than if you did not have the DKIM signature.
> Proving something always comes with assumptions and caveats. Even if we're talking about proving something cryptographically, the underlying assumption is that crypto primitives are unbroken or that participants retain control of their keys.
Absolutely. Propositions have a premise and a conclusion. In regular conversation, it is usually safe to omit part of the premise when it is assumed that everyone is on the same page, otherwise communication would be overly laborious. I agree 100%. An example in my response: I said nothing of the assumption that the cryptography in use hasn't been broken through quantum computing or other means as I think it's pretty obvious that, if verification of authorship hinges on the cryptography functioning as intended, it should be apparent that "the cryptography hasn't been broken" should be part of the premise. Communication would be practically impossible if we all have to add in an infinity other ground truths, like "the brains of humans of earth haven't been taken over by extraterrestrial parasites", or "we're not talking about a point in time before humans came into existence", or whatever.
> In this context, DKIM definitely proves a user sent an email if you're willing to accept the assumption that the email provider is not arbitrarily sending emails that users did not write.
I was waiting for this comment.
I'll restate your proposition, to make it more explicit:
"If an email provider won't arbitrarily send emails that users did not write, then a valid DKIM signature for a given email entails that the author as indicated in the FROM header was indeed the actual person/entity that wrote the email."
And that's fine!
So, if we take the premise to be true (as it seems you do), then we arrive at "a valid DKIM signature for a given email implies that the author as indicated in the FROM header was indeed the actual person/entity that wrote the email". Great!
However, to clarify why I wrote my original comment, here's the important bit from the OP:
> 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.
There's nothing about this that suggests that this commenter would find the earlier proposition invalid. More than that, if we are charitable (as we should be, if we want civil, productive discussion) and assume that they actually do consult in this space, there is no reason for us to assume that they don't already hold this proposition to be valid.
What the original commenter wrote could be restated as:
"If an email provider is not trusted to not send arbitrary emails, then DKIM is not sufficient proof to trust that the supposed sender actually authored the email -- it is only sufficient proof to trust that the email was delivered via the respective email service."
Looking at your response to the original commenter:
> You are technically correct (the best kind of correct), but in practice the nuance you're referring to does not make as much difference as you think. Yes, email senders could send email from whatever user they want or change the body from what the user wrote, but in practice of course they aren't doing that for the kind of email providers like Gmail that most people use.
Okay. Sure. You trust Gmail or whoever. That doesn't invalidate the second proposition -- that just means that (under your world view) it is not satisfiable.
Ultimately, what I was initially responding to:
> 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.
comes off as uncharitable at best, and undeservedly antagonistic and offensive at worst. Your response thus far hasn't provided a valid counterpoint.
And, to be clear, I actually disagree with the original commenters assertion:
> 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.
(edit: TBC, I think this statement is true but doesn't effectively refute the utility of publishing the keys -- that, if everyone has the old key, the signatures of old emails become useless, while the signature of a new email can still be used to check authenticity... that authenticity, of course, being predicated on the assumption that Gmail or whoever isn't sending fraudulent emails, which admittedly is a pretty safe bet)
But that's orthogonal to what this sub-thread is discussing (whether second proposition above is valid), which started with someone snarkily implying that someone else is incompetent in their field.
> a DKIM-signed message proves the mailhost was authorized
That is what I wrote, I may have not have explained it correctly though, I was in a bit of a rush earlier today.
DKIM signs (a selection of) the headers, and the message body. The sender address (the 'from' header) is typically included in the signed subset of headers.
The domain (the part after the '@' symbol) authorizes the sender (the owner of the private key) to send email on behalf of the domain by publishing the public key (the DKIM DNS record).
So, if the signature is correct, then you know the message body, and the headers included in the signature (such as the 'from' header) are authentic (not tampered with since the host set added the signature). You also know that the sender is authorized to send email on behalf of the domain.
However, the sending host is free to place any arbitrary data in the headers, including the 'from' header, and sign it. There is absolute nothing that will prevent a malicious host from placing an arbitrary name before the '@' sign, except for integrity. So just because 'jane' was in the 'from' header, it doesn't mean that Jane actually wrote the message.
> and at least some of the headers could easily prove who sent the message.
No, none of them do. As I explained above, the sender is free to set the header values to any value. So just because there is a name in 'from' header, doesn't mean that that person actually wrote the email, or that it originated from one of that person's devices.
If you publish the DKIM DNS record for some third party email service, then that service could very well send email as you@yourdomain.tld. Should that somehow "easily prove" that you send that email? No amount of email headers are going to protect you from that kind of malicious behavior, that's just not how email works.
> You should probably stop "consulting on email security" if you don't understand [...]
Please refrain from insults like that. Reading your comment mocking my profession like that really ruined my evening.
You are technically correct (the best kind of correct), but in practice the nuance you're referring to does not make as much difference as you think. Yes, email senders could send email from whatever user they want or change the body from what the user wrote, but in practice of course they aren't doing that for the kind of email providers like Gmail that most people use.
If the deniability of a DKIM signed email reduces to "maybe Gmail spoofed emails from me", you don't have much of an argument. Yes, in a technical cryptographic sense, DKIM does not prove you sent the email, but when combined with how most providers like Gmail work, it makes it very likely you did send the email in every practical sense.
This isn't just a nitpicking nuance. In theory, rotating and publishing DKIM keys makes no difference to deniability since DKIM doesn't technically provide non-repudiation at the individual user level. In practice though, a service like Gmail implementing DKIM rotation and key publishing would make emails for a huge number of users more deniable going forward.
Yes, this is the point. Most (nearly all?) of the publicly available providers a user is likely to use won't allow you to use their MTAs and set From headers in a way that would impersonate someone else on that domain, provided you're authenticated as yourself.
So pointing out DKIM only authenticates the domain only weakens the argument from "UserX at Gmail sent this email" to "UserX at Gmail sent this email provided no one found a suitable, currently unknown exploit at Gmail or performed an inside job".
For a journalist and most juries, provided the absence of any reasonable suspicion or evidence of weaknesses / foul play at Gmail, both statements have equal strength.
>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.
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).
> 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.
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.
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?
No. You can have multiple DKIM DNS records (each identified by an id called selector). Each DKIM signature includes the selector. When you change keys, you create a new DNS entry with a new selector, then change the settings of the mailserver. New mails will then be signed by the new key with the new selector. Old mails can still be verified until you delete the old DNS entry.
> 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.
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.
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.
But there is a chain: 1) the mail provider only allows outgoing mail with a particular Return-Path / Envelope Sender / From header if it has done authorisation checks to ensure the sender is allowed to use that address, 2) the mail provider DKIM-signs their outgoing mail.
The combination of 1 and 2 work together. Yes, the mail provider could impersonate you, or could fail to do (1) correctly, but that is a different threat model to one where having no verification at all is okay.
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.
There isn't such a layer for email that is widespread (there's certified email in Italy). PGP and S/MIME crucially lack time and validity stapling.
In a lot of EU countries you can however digitally sign a container and mail that (under eIDAS those qualifying electronic signatures are legally binding, unlike random publicly trusted S/MIME signature).
But I guess if your alternative is fax, then a lot of thimngs are better than that.
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.
But the sender chooses an e-mail service that sends e-mail in a way they aprove of.
The receiver has no control over that besides possibly ignoring those e-mails, therefore the e-mail services favor the interests of the sender over those of the receiver.
> 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).
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.
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 frame job is not a stretch. I’ve seen spear phishing campaigns that spanned weeks to convince someone that’s request to transfer money, at the very end, was legit. Some of the intermediate emails were pretty innocuous.
That’s just impersonation, framing is when it’s about how you make the real party look, not yourself. Which would be weird, not implausible, but you get to implausible when you assert not just that somebody framed you, but that you were framed by some specific trusted party like the police or Google, and also you have zero evidence.
People fake emails all the time: see examples in this comment thread. Literally all it takes is a text editor. This is not the same thing as a criminal frame job, where someone is going to put your fingerprints on a knife at a bloody crime scene.
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).
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/>
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.
The point is that it allows something it is not designed for. I don't think anyone is against it because it hurt their political party, the cat is out of the bag on that front anyway.
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.
The point of this proposal is that with rotation someone could not prove that a message hadn’t been forged retrospectively. It would then be almost impossible to establish an airtight chain of custody
That does not break the scheme at all? In fact it is counting on it. The point is to publish the private keys, which would match the public keys in your database.
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?
> 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?
Not really, not when people have been arguing for this setup as a best practice for years for whole domains.
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.
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.
Sorry, this is incorrect. Non-repudiation is undesirable for email senders. It is desirable in some other systems, such as notarization and the signing of contracts.
Would you be comfortable about having everyone you interact with secretly videotaping and recording you, and possibly publishing embarrassing clips 5 years later?
Deniability allows you to have low-stakes, casual interactions rather than having every stupid utterance timestamped and notarized for possible public viewing later.
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.
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.
reply