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/[email protected]/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.

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

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.