6 ms·

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: opinio

by LeonM 3y ago

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.

proto_lambda 3y ago
> 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.
- djbusby 3y ago
  Sounds like spammer could use the key then too? Send DKIM signed message from my domain?
  - proto_lambda 3y ago
    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.
    - LeonM 3y ago
      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.
      - nulbyte 3y ago
        > 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.
      - A1kmm 3y ago
        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.
rcxdude 3y ago
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.
- layer8 3y ago
  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.
  - rcxdude 3y ago
    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.
    - layer8 3y ago
      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.
      - rcxdude 3y ago
        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.
denton-scratch 3y ago
> in most cases this won't even be possible, due to the use of HSMs. Most holders of keys do not own an HSM.
- LeonM 3y ago
  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.
  - gsich 3y ago
    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.
    - nmadden 3y ago
      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.
      - gsich 3y ago
        For mailservers though? It this scaleable if you start/stop machines on demand.
        nmadden 3y ago
BoppreH 3y ago
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.
- zajio1am 3y ago
  Well, there is also third option: the sender account was compromised. But yes, it is still pretty strong evidence.
- klausa 3y ago
  >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.
  - pnpnp 3y ago
    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.
- chias 3y ago
  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.
salawat 3y ago
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.
KennyBlanken 3y ago
> 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.
- cstrahan 3y ago
  > […] 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.
  - rainsford 3y ago
    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.
    - cstrahan 3y ago
      > 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.
NovemberWhiskey 3y ago
>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.
brightball 3y ago
Thank you for saving me the time on this. I was about to echo the same.
petejansson 3y ago
> 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).
DoctorOetker 3y ago
> 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.

by LeonM 3y ago

proto_lambda 3y ago

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

djbusby 3y ago
Sounds like spammer could use the key then too? Send DKIM signed message from my domain?
- proto_lambda 3y ago
  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.
  - LeonM 3y ago
    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.
    - nulbyte 3y ago
      > 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.
    - A1kmm 3y ago
      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.

rcxdude 3y ago

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.

layer8 3y ago
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.
- rcxdude 3y ago
  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.
  - layer8 3y ago
    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.
    - rcxdude 3y ago
      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.

denton-scratch 3y ago

> in most cases this won't even be possible, due to the use of HSMs. Most holders of keys do not own an HSM.

LeonM 3y ago
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.
- gsich 3y ago
  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.
  - nmadden 3y ago
    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.
    - gsich 3y ago
      For mailservers though? It this scaleable if you start/stop machines on demand.
      - nmadden 3y ago

BoppreH 3y ago

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.

zajio1am 3y ago
Well, there is also third option: the sender account was compromised. But yes, it is still pretty strong evidence.
klausa 3y ago
>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.
- pnpnp 3y ago
  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.
chias 3y ago
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.

salawat 3y ago

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.

KennyBlanken 3y ago

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

cstrahan 3y ago
> […] 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.
- rainsford 3y ago
  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.
  - cstrahan 3y ago
    > 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.

NovemberWhiskey 3y ago

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

brightball 3y ago

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

petejansson 3y ago

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

DoctorOetker 3y ago

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