0

I'm trying to build a way to prove that an e-mail was indeed sent from a specific domain.

Is there a service that allows me to demonstrate what value a TXT record had at a certain time, e.g. by providing a signed DNS response, or an archive of past DKIM/ARC keys?

Background:
Nowadays, many e-mails come with DKIM (and sometimes ARC) signatures. However, these can only be validated for as long as the corresponding key remains available. I can of course archive a copy of the key, but I cannot prove to a third party that this key was indeed the real key used by the sender at that time.

The ideal solution, in theory, would be DNSSEC, but this would have to be deployed by the sender and it doesn't seem to be common, even among large senders (checked for Google's DKIM key and Microsoft's ARC key).

There are commercial DNS archives, but the two I checked (securitytrails.com and completedns.com) didn't even list Google's DKIM key, so I don't believe these to be particularly useful.

A workaround could be archiving a web-based DNS lookup tool in archive.org, but I was looking for a cleaner/more scalable solution that could easily be applied to incoming mail.

I do understand that DKIM is not as strong as e.g. a qualified electronic signature, that DKIM keys can be compromised, that accounts allowing someone to send from the legitimate server can be compromised, and that DKIM keys could be intentionally released once they're no longer used in an attempt to create plausible deniability for past messages. The latter can be mitigated by obtaining a RFC 3161 timestamp for the message.

An example scenario where this would be helpful: You owe a company money. The company sends you an e-mail instructing you to wire the money to a specific account. You wire the money, but it turns out the company was hacked, the account number in the e-mail was replaced, and the money is gone. If you can prove that you verified that the mail indeed came from the company's server, and that this mail already contained the wrong account number when it was sent from there, you have a much better chance that a judge will not require you to send the money again.

Jan Schejbal
  • 171
  • 3
  • In what sort of legislation could someone pretend a *business email compromise* did not happen and not be on the hook for much worse than just the money you transferred? – anx Nov 19 '20 at 17:09
  • Seems related: https://blog.cryptographyengineering.com/2020/11/16/ok-google-please-publish-your-dkim-secret-keys/ – Patrick Mevzek Nov 19 '20 at 19:29
  • @PatrickMevzek: Yes, the post reminded me to look back at this project. As the post even mentions (hadn't read so far down), timestamping is an obvious countermeasure against providers publishing old/rotated keys. While the sender may obviously be interested in the ability to deny that they sent the mail, I as the recipient am (obviously) interested in being able to prove it. – Jan Schejbal Nov 20 '20 at 20:07
  • @anx: If they deny it (e.g. because they don't even realize what happened), I may have to prove that it was "their fault" or risk the judge telling me "I don't know where you sent the money, but you didn't pay them, so pay them." – Jan Schejbal Nov 20 '20 at 20:10

1 Answers1

0

Other than logging the DKIM/SPF check results from your mail server, there's not much you can do. DNSSEC further allows you to "validate" that you actually got the correct DNS answer at query time, but this is handled by the DNS implementation on the mail server and probably not visible to the mail server application itself. Another way would be to catch the key identifier in incoming mail and then out-of-band query the same key via DNS. That way you could store the public keys returned by DNS and verify email against them.

Sadly what you're trying to do is a bit outside the intended use of DKIM and DNSSEC. DKIM and SPF are intended to verify the authenticity of the sending server at the time the message is received from a remote entity, and DNSSEC is intended to authenticate DNS responses at the time of query, and all of them are only intended to authenticate the infrastructure of the remote party, not the sender itself. For example, a compromised user account sending email from a remote party would still pass SPF/DKIM and DNSSEC.

A more "correct" technology for proving that an email originated from the correct party would be S/MIME or PGP, which can be used to sign individual email from a single user, and doesn't take into account anything about the transport infrastructure. PGP public keys can be stored indefinitely, which allows you to retrospectively verify authenticity of emails received.

Stuggi
  • 3,506
  • 4
  • 19
  • 36