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.

Well, there is also third option: the sender account was compromised.

But yes, it is still pretty strong evidence.

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

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

Because emails, fundamentally, are not, and cannot be, a secure messaging systems.

Why not? PGP has proven that it’s possible.

You can certainly invent a better greenfield solution than email in 2023, but that’s not to say email doesn’t have room for improvement.

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.

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

By the time you publish the key, it is no longer in your DNS records and thus no longer trusted by any receiving mail server.

There lies the problem IMO.

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.

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

> every time this article pops up

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

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

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

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

> […] 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.

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

Most holders of keys do not own an HSM.

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.

For mailservers though? It this scaleable if you start/stop machines on demand.

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 key can obviously be extracted from the HSM, making publishing it possible.

As I understand it, it should be impossible to export a private key from an HSM.

I'm not very familiar with HSMs though, so I might be wrong about this.

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 can with almost 100% certainty tell you that none of the major providers use HSMs for their DKIM keys.

Use how?

From what I understand, they can do more different things than "private key never leaves the device" asymmetric stuff.

Thank you for saving me the time on this. I was about to echo the same.