DKIM: Show Your Privates | Hacker News Reader

DKIM: Show Your Privates

rya.nc

132 pointsryan-c72 comments

Can someone explain this entire article in simpler terms? I read the other comments here, but they weren’t helpful for me.

I understand technology, I understand the concepts of public key cryptography, I think I understand what DKIM is used for (verification that the specific domain’s server did send a specific email because it’s signed, which can be verified by the receiving party using the key published in the DNS record)...yet I found this article to be terse (along with the short Twitter thread initiated by Matthew Green).

Is the author just building plausible deniability by publishing the keys? Would this even truly stand up as believable for any scenario? And why is Matthew Green suggesting this?

Thank you very much!

>Is the author just building plausible deniability by publishing the keys?

Yes.

>Would this even truly stand up as believable for any scenario?

The post says this will most likely only work in a leak situation rather than a legal dispute. An example of where this might be useful: You send an email to a friend revealing something sensitive about yourself. A hacker hacks your friend's email and leaks it out. Without plausible deniability, everyone can verify cryptographically that you did in fact say that sensitive stuff (assuming your own email didn't get hacked). With this technique, people cannot verify whether or not you said it, the email might be a fraud and so people are less likely to believe the sensitive thing about you.

> With this technique, people cannot verify whether or not you said it, the email might be a fraud and so people are less likely to believe the sensitive thing about you.

If the recipient can prove he had the signed email before the signing private key was made public, eg, by contemporary third party notarization, the keys becoming public later don't help with disclaiming it at all.

Yes, that's the point though: To make DKIM not serve as a non-repudiation mechanism. It forces actors to go through other notarization steps instead of relying on DKIM.

> Yes, that's the point though: To make DKIM not serve as a non-repudiation mechanism.

The devil is right in the details... it is serving just as perfectly fine as a non-repudiation mechanism as it ever was, just constrained in time to a day or so as suggested by the article. Depending on what you said to whom that you wish you hadn't said, that can be all you need to get into trouble.

Are you familiar with the concept of Post-Compromise Security?

There is no compromise and no security breached. Just a guy who really did say something and wishes there was no evidence he said it.

Publishing the privkey just makes it so in other circumstances where he might strongly wish that he had evidence he HAD said something, the dkim signature is devalued.

The author is nonbinary, not male.

I'm not a he, but you're correct that a counterparty can easily break delayed key disclosure as a way to have plausible deniability. This was brought up in the Twitter thread (though reading a conversation on Twitter that has any forks is... a chore) started by Matthew Green.

Yes. In the specific example that I gave though (the recipient being your friend), it likely wouldn't happen because your friend is not going to get something notarized to use against you. There could still be a problem if the hacker has control of your friend's email account while you send your email, because then the attacker can get it notarized.

Thinking about this more, maybe an alternate technique to provide plausible deniability is to setup a service that acts as a signing oracle with your private key. To avoid it being used for impersonation you might be able to implement a system that receives signing requests via email, and will only sign emails that have the "to" address equal the source of where the signing request came from.

Attack: Sign up for email accounts at major providers, use the signing oracle to sign spam emails, submit to provider, domain's reputation becomes spammy.

The handling rules standardized by DMARC are to ignore failing SPF when there is a valid DKIM signature, even if the domain doesn't use DMARC. Google, in particular, ignored SPF failures on DKIM signed messages last I checked.

Interesting. What if you required payment, say via Monero, for each signature? That would slow down the creation of spam emails.

If you're a low volume email sender, anything attributed to your domain getting marked as spam can cause serious pain. It's an interesting idea, but not an experiment I care to run.

As long as no one archives your DKIM public keys which are available to anyone who asks.

Why would people archiving your DKIM public keys be a problem?

Sorry I think I misunderstood your post. You are right.

I can imagine why the author could maybe want plausible deniability against potentially leaked or forged emails, but I definitely see DKIM and non-repudiation a feature. I suppose the caveat is that if DKIM private keys were stolen, fraudulent emails could be convincingly generated, but this isn't a normal concern for users of the big hosted webmail services.

One valid use case of non-repudiation that I can think of is the Poor Man's Copyright[0], where you email yourself your creative and have a timestamped record of when it existing.

[0]: https://en.wikipedia.org/wiki/Poor_man%27s_copyright

Poor man's copyright is unfortunately quite tenuous and usually unenforceable.

At my start-up we've built an analogous system which instead uses a public blockchain for notarization (as dirty as that word has become). https://assembl.net or https://app.assembl.net if you'd like to try timestamping right away.

Non-repudiation here is useful, but the timestamping is the more important piece.

OT, but if you're going to use a miss-spelled word, by not get one with an available .com?

Eh, fair question. Assembl is a pretty sought after name which we have the trademark on. I came up with the name after thinking it was necessary to "assemble" teams of scientists for collaborative research. I liked the name "Assembl" as it's the root for "assemble", "assembling", "assembly", etc.

- https://assembl.org and

- https://assembl.co

are both infringers, but we haven't decided to go after them. The owner of https://assembl.com cannot be compelled to sell it, but can't sell it to anyone but us. For now, the focus is mainly on providing value to our userbase, as we grow these challenges are surmountable.

Sounds like a managed issue. Good luck. FWIW, I like the name.

How is it unenforceable if DKIM offers cryptographic non-repudiation practically similar to embedding* the hash of the item§ in a public blockchain?

* This is an assumption

§ I understand that you may be embedding Merkle roots to keep costs low.

From the wiki article YOU quoted (USA specific)

> there is an absence of cases actually giving any value to the poor man's copyright.

Yes, but that doesn't mean it can't be unenforceable. It simply means it hasn't passed the test of a court. However, isn't the same, from my limited research and knowledge, true for blockchain-based notarization?

https://cryptoadventure.org/blockchain-in-courts-a-look-into... blockchain timestamping is pretty well tested.

Edit: I would really appreciate it if the downvoters would at least attempt to have a discussion. The dogpiling tactic seems to be rather thoughtless.

I would refer you to https://cryptoadventure.org/blockchain-in-courts-a-look-into....

Poor man's copyright without cryptographic proof or an immutable time boundary is pretty much worthless.

DKIM does not offer cryptographic proof-of-existence or proof-of-time, which a blockchain does. That's the only functional difference, but crucial for copyright law.

DKIM makes no assertions about the timestamp. It can be anything you want, just as in any other email.

The signature can confirm parts of the email were not edited after it was signed, not that any of the contents were ever true or correct.

What if you send the email from a reputable managed email service? That way, they're responsible for managing the keys, and can probably be trusted not to sign anything fraudulently.

Cheaper than paying for a digital signing service, but I imagine it wouldn't hold up as well in court.

In the default setting, where it's not explicitly part of the security model, non-repudiation can be a vulnerability. A message is exchanged between counterparties, who verify its authenticity; they now know what they need to know. Allowing unrelated parties to reliably verify the message is conceding information to them. This is, for example, the reason that OTR deliberately leaks secrets after they're used.

It's easy to see an example scenario: someone steals your laptop, then posts your mail spool publicly. You'd like to be able to say "you can't trust any of these messages", to mitigate the damage.

What I think confuses people is the fact that there are settings where non-repudiation is crucial to the security model. We're used to abstract cryptographic promises that apply universally to all systems. But this one doesn't.

> someone steals your laptop

I wonder how well the non-repudiation would actually hold up in that scenario. If you self host your mail server, the attacker could possibly steal your private key and forge the emails. So you might actually have repudiation. Or does DKIM have a timestamp? If not the attacker can simply send an email from your laptop and get it signed by your mailserver. Thus another route for claiming repudiation.

I'm not sure how common it is, but my mail server in particular doesn't store the signed emails, and I went to no special effort to set things up that way.

Of course, if someone replies to me and quotes my email to them, that will be signed by their server's key.

I'm not sure what you're saying. Whether or not the mail server stores emails has no bearing on what I said.

My reply was more to what tptacek said - observing that for at least some configurations a stolen mail spool from a laptop won't have signatures on sent emails.

Oh, interesting point. Yeah, maybe stealing your laptop will only give attackers proof of what your acquaintances said, not what you said.

For context, this idea of publishing the secrets has come up again recently after DKIM was used to prove the authenticity of the “smoking gun” Hunter Biden email. [1]

More generally, non-repudiation is a great feature if that’s what you’re going for. Often times it’s not actually what you needed at the time, but gets thrown in anyway because it’s harder to design a signing protocol without that property than with it.

So in the sense that non-repudiation isn’t a core requirement of DKIM you’d like to have the crypto algorithm which meets just the DKIM requirement and no more — yes, this email definitely came from an authorized server and hasn’t been tampered with, but without inherently proving that the email is not a forgery years later.

On the other hand, DKIM having this property is actually extremely useful and nice to have a lot of the time, not the least of which in the Hunter Biden case, or for the purpose of authenticating any particular historical email.

[1] - https://github.com/robertdavidgraham/hunter-dkim

Purely from an engineering perspective, in a setting where we care about privacy --- ostensibly, email is one of the settings where we care most about privacy --- the ability of a stranger to authenticate any particular historical email is a fairly grave vulnerability. Privacy-preserving systems go out of their way not to have it.

You may have some kind of public policy or archaeological argument in favor of the vulnerability, but then it's hard to see how the same argument doesn't suggest we should compromise the entire confidentiality of every email; after all, that would make research a lot easier.

just for the record, while I mostly agree with the analysis on that page, I believe the author tries to make a stronger case than it really is.

1) DKIM verifies the To: header, not the "rcpt to" receipient. The To: header has no value in determining who actually received the email. (Ex: you receive the email via BCC, you can't verify that the recipients listed in the To: actually got the email).

2) GMail actually does let users "spoof" the From: line. it needs cooperation from the "owner" of the address you want to use in the From line, but it is possible, and once set once, is never reconfirmed.

so, as I said, while I generally agree with the analysis, but I think 2 statements it makes are a bit too strong

1) "it was sent from this specific account, v.pozharskyi.ukraine@gmail.com" - It could have been sent via a different account that got the specific account's permission (either via a hack of sorts or cooperation) to spoof it. I'd agree that this isn't that likely.

2) "the intended recipient was to the account hbiden@rosemontseneca.com" - all we can know is that this was the To: line, it is very easy to spoof this. (every email one gets via BCC is essentially spoofing this).

do I think either points are very likely? Not so much, but any page trying to prove the authenticity needs to address the limits of the analysis, which the author didn't do.

Of course there are other assumptions we make, notably that no one was able to steal or crack Google's old DKIM key. I wonder how many google employees would have had access to this DKIM key over time (and if security procedures might have been relaxed once it was "expired" and the public portion no longer distributed).

DMARC does a decent job of solving a few of those points. Alas, that only proves the point that another commenter made about server-to-server SMTP being a hack-job piled on top of another hack job.

The one thing DKIM is good at is for protecting the From-header and body from modification, allowing receiving servers to verify that the sender is genuine whenever they receive an incoming message (when combined with DMARC that is). For anything else, use PGP, S/MIME, or something else that actually does end-to-end encryption/signing.

Of course, this scheme only works if the leaked emails are published at least 10 days after the day the email was sent. If we build non-repudiation into the DKIM framework itself we can do better, as this paper does.

https://www.mit.edu/~specter/assets/pdf/sec21KF.pdf

Trying to retrofit "we guarantee this really came from this person on this date" features onto server-to-server SMTP transport is a losing game in my opinion.

I've been running smtpd on the Internet since 1996, for ISP purposes.

DKIM is all fine and good, and a beneficial thing as part of a multi pronged anti spam approach, and for the general health of the Internet.

But it's not meant to be used with rotating a key every day. My worry is that some hacked up setup like this will provide people with a sense of false confidence that shouldn't exist.

Email is still like a postcard, not a sealed envelope.

I would consider it a very poor idea to have a set of automatic scripts messing around with the MX records or DKIM records on the domain zonefiles on my set of authoritative-only nameservers. Those things aren't meant to change often.

All of the considerations involved in setting up and running your own smtpd in a highly reliable manner in the year 2020 (not just pointing your MX records to office365 or gsuite and calling it a day)...

Yes you should run DKIM. You should pay attention to stuff like DMARC, SPF, your IP space reputation, proper configuration of your smtpd, your own smtpd's configuration to discard incoming stuff based on RBLs and spamassassin, as I have my postfix system set up to do. But ultimately server to server SMTP in the year 2020 is a hack job piled on top of a hack job.

There is no need to start doing things that require you to set very low TTLs on your domain zonefiles and then blindly trust that every caching DNS resolver out there on the internet will respect that (breaking news: they won't! it will break mail delivery in new and amazing ways!).

If you want a proper cryptographically secured end to end communication method, it's not anything that speaks SMTP. Go use Signal to chat or something.

The "hack job piled on top of a hack job" argument doesn't amount to as much as you seem to think.

This weekend Rescorla et al published the Internet Draft of Compact TLS. cTLS is (intended to be) exactly the same functionally as TLS 1.3. Except that the "spelling" is er, compact.

For example, your "real" TLS 1.3 connections have a connection ID in them. That seems sane right? Well, the content of that ID is a bunch of random gibberish, echoed back by the server. It doesn't do anything useful at all, it isn't identifying anything, it's just some random bytes in a system that already has dozens of random bytes that are there on purpose anyway. So why is it there? It's there because in TLS 1.2 that connection ID field was used to resume previous sessions and so lots of middleboxes will just assume everything must be fine so long as you fill out the connection ID and then the remote server appears to continue the same session. Such middleboxes can't snoop because they don't know enough about this hypothetical session which never happened, but since they are just security theatre anyway it doesn't matter, your connection succeeds. This makes TLS 1.3 actually work, developing such workarounds by tweaking the "spelling" took about a year.

But the security proofs are the same for compact TLS and the "real" TLS 1.3 shipped in your browser. It's just that the real thing is "a hack job piled on top of a hack job" because that works.

Mathematics doesn't care how you spell it, if you've come up with an incredibly convoluted way to do something apparently easy, but the math checks out anyway, it still works.

Server to server TLS transport is of course something I have set up on the smtpd I run. However I don't expect it to provide real security for email transport, since SMTP traffic could go through any amount of plaintext hops outside of my control on either side of an mx to mx communication session.

And my mx also needs to be backwards compatible to exchange email with older systems out there on the internet that speak no TLS at all.

I don't dispute the merits of tls1.3 in any way, or that it functions as designed.

Aside from email, the entire centrally hierarchical root CA system is a hack job. Why does your browser trust certificate authorities from turkey and mainland China?

CA cert issuance transparency and public logs are a further hack job piled on top.

Maybe I didn't do a great job of making my point. You dismiss this as "a hack job piled on top of a hack job" and I gave another example of such a thing (TLS 1.3) which you agree is in fact secure anyway. My point was that this argument is, at best, flimsy.

My point wasn't that magically the existence of TLS 1.3 makes email secure but that TLS 1.3 is "a hack job piled on top of a hack job" too and it's fine.

However, since we're here now: Depending on which browser you use there are two potential answers to your question.

In Firefox the answer is always that Mozilla decided that the CAs which are members of its root trust programme met its requirements. Mozilla's oversight of the Web PKI happens entirely in public. If you have a specific reason to think there's a problem at a CA based in Turkey or Mainland China which is a member of that programme you should raise it.

Otherwise, this decision was made by your OS vendor. If you use a Free Unix then in effect that's still Mozilla since all the popular Free Unix system implicitly or explicitly delegate this to Mozilla, but if it's Google, Apple or Microsoft then that's a matter for them, and they do not have public oversight, good luck with that.

Now, since you mentioned Turkey and Mainland China specifically that would narrow things down a lot (unless you run Windows). Mozilla only trusts Kamu (the Turkish government CA) for Turkish stuff, so, it's unclear what sort of threat you imagine they impose. When I say "Turkish stuff" I mean like the Turkish government's sites, its military, schools that sort of thing, not say a Reddit about Turkey. TURKTRUST which you might have heard of is not trusted at all.

When it comes to the Chinese mainland (as opposed to Hong Kong or Taiwan) there are several more, including GDCA and CFCA but we don't have any particular reason to doubt these authorities behave in accordance with policy. They seem to be exactly what you'd expect, for example CFCA is a financial outfit, and sure enough it issues certificates to various Chinese banks. Would it be a good idea for a foreign critic of China to keep money in those banks? Perhaps not, but that's hardly a problem with the CA.

I'm not sure why you say "these things aren't meant to change often". If you rotate your keys, or make tweaks, then they change as often as that happens.

There are potential problems of buggy-scripts nuking MX/DKIM/other records (though perhaps the A-record will be used as a fallback, not all clients do that). But "buggy scripts" can take down everything and anything, SMTP is not special in that regard.

One of the reasons I love my DNS-hosting/reselling service is because it uses git for revision control. I can happily commit DNS records, revert them, and have them reviewed via pull-requests, etc. I'm not the first person to have done that, but it has been very useful https://dns-api.com/

As a side note, if you host your own authoritative nameservers (such as a very basic debian or centos + bind9 setup), you can set up your own self hosted gitlab and oxidized to retrieve the contents of /etc/bind/ on a cron job, put them into git and store them for revision control.

https://www.google.com/search?channel=fs&client=ubuntu&q=git...

I'm not familiar enough (or at all) with DKIM internals to know which side is broken, but I had a DKIM verifier extension on Thunderbird, which would verify either against a cached key or the current key.

One person who emails me rotates their keys often (weekly or so), and unless I read and verify it a day or two after it is sent, the verifier complains, and there's no way for me to know that the message is authentic. I have to trust my service provider that they did a timely DKIM verification, and I don't want to do that.

In my opinion that's not what DKIM was ever meant to do. Yes a email client can examine dkim headers and do something based on that. But it's much better used as a method for influencing a metric of spam or not spam on your MX smtpd that receives incoming traffic. Not as a guaranteed 100% "this is legit" indicator. It's a thing used to influence a weighting score on my postfix setup.

Note that there is not a lot of technical barrier preventing a spammer from setting up a very basic opendkim daemon and key, and using a one time throwaway domain name to spam from, along with the appropriate dkim records in the DNS zonefile. But it's a barrier that not a lot want to jump through.

Used as you suggest, there’s a good chance a fishing/scam email will go through since it only affects spam score.

I’ve had several scam emails, including from @paypal addresses, which did pass my mail service’s filter, but flagged by the DKIM verifier.

I want defense in depth; I’m ok with the occasional visible false warning. Rotating DKIM keys often makes it unusable on the mail client. (Not sure that’s a problem with DKIMs intended use, but if keys are rotated slowly enough - e.g. once a month - it’s usable for that too)

If it came from a fake "paypal.com" address but was not received from the MX for paypal.com, your incoming spam filtering has issues other than DKIM... Something like that would get 5+ extra points added to it by a basic spamassassin setup. With a common setup that is postfix + opendkim as a mail filter on the incoming, that should also get caught.

I guess the point I was trying to make is that DKIM was really intended to be deployed on the service-provider side, and smtpd mail filtering side, rather than on the client.

I agree they did something wrong. But I don’t run my own server - and I do run my own client....

And it’s not the MX that says where mail comes from, it’s the SPF record (if you have one).

Google had, for a very long time, an issue where any g-suite/gmail user could SPF as any g-suite domain; so servers that didn’t check DKIM (most until recently, and probably still) would let it through happily.

Just to be clear, the post is about minimizing the limited non-repudiation properties that DKIM is currently giving email as a side effect.

> I would consider it a very poor idea to have a set of automatic scripts messing around with the MX records or DKIM records on the domain zonefiles on my set of authoritative-only nameservers. Those things aren't meant to change often.

These are entirely reasonable concerns, and I have a dedicated zone for _domainkey.ryanc.org set up to manage that risk.

> There is no need to start doing things that require you to set very low TTLs on your domain zonefiles and then blindly trust that every caching DNS resolver out there on the internet will respect that (breaking news: they won't! it will break mail delivery in new and amazing ways!)

Also true, and it's why despite the 5 second TTL I wait days between revoking the selector and publishing the private parameters.

Were you aware of https://as397444.net/dkim/ e.g. https://as397444.net/dkim/as397444.net/ ?

( He writes a notice in the headers https://twitter.com/as397444/status/1291178153084428288 )

Also this thread: https://www.mail-archive.com/mailop@mailop.org/msg10962.html

I was not, thank you for the link.

I've been running my key disclosures for over three years, Matthew Green's Tweet about it motivated me to write it up.

I agree with this. I would also add that DKIM does not mean I created those keys. Many email providers today implement DKIM for their users. Fastmail is a great example of this. I have a few domains pointed to fastmail for family members to use. Their emails are DKIM signed. That signing is from fastmail, not my family members. If their account password is compromised, the attacker can also send DKIM signed emails. IP addresses are also useless in any case. Malware can be used from a family members PC to log into email. So DKIM is really just useful to minimize spoofed emails for accounts that are not hacked.

It's not really non-repudiation if the keys are not controlled by the author of the email. In the case of Gmail, Google is signing the outgoing mail on your behalf. Anyone at Google, and anyone with access (whether obtained legitimately or not) to your Gmail account, could have written the email.

There are degrees of non-repudiation. In a court of law, you may be right - there is reasonable doubt as to authorship. But when a public figure's emails leak to the New York Times, the standard might be a little lower.

> ...email providers to try deploying a key management strategy similar to the one I’ve described in this post.

Assuming author meant key rotation, Protonmail[1] offers automatic key rotation by using CNAME that alias to DKIM TXT which is rotated once in a while.

[1]: https://protonmail.com/support/knowledge-base/anti-spoofing/

Automatic DKIM key rotation is common, I'm talking about publishing private keys.

For a practical example, see https://github.com/robertdavidgraham/hunter-dkim

The fact you're getting downvoted lays bare the bias of HN. Cryptographic proofs (math) clash against ideology, and ideology wins.

It's funny how the top comment in this thread is someone asking how leaking your public key would ever be useful. And a comment giving a very concrete example of how it's useful is at the bottom.

Oops, I meant to say "private key".

The repo was posted on HN and pretty much flagged immediately.

Maybe the average HN user would rather keep cryptography in the cryptography discussions and ideology in the ideology discussions. I don't necessarily agree with that, but it's not evidence of "bias".

It would have been nice if the original post mentioned this.

Or you could just use S/MIME. DKIM wasn’t designed for the purpose the author describes. But S/MIME works great for this purpose.

Alas, S/MIME is relatively complicated and can't really be used by the general public without re-teaching everyone how email work (lost keys will be a support nightmare). But yeah, S/MIME signing is incredibly useful for the specific purpose the article suggests.

Is anyone else incredibly put off by the title of this article? It may be a pun, but an extremely insensitive one that just comes off as callous, especially given that we're in a period of time where very real repercussions of a careless attitude towards cutting-edge technology are increasingly coming to light (e.g. DeepFake being used maliciously).

The article's fine; seeing this title on my news feed just made me feel sad.

Agree - the title grabs the wrong kind of attention. It's sad to see the deeply technical realm co-opted by the same kind of clickbait attention-seeking that powers celebrities/social media/etc.

Reply on news.ycombinator.com