MTA-STS or the worst of everything…
Preambule
This is a rant. You are warned. Expect strong language. There be Dragons. You can still get away.
I have been protecting my personal DNS zone with DNSSEC for quite some time, it was not difficult, I used the “DNSSEC in 6 minutes” presentation a few years ago and it worked. I have changed the way I manage my zones mainly because Let’s Encrypt happened in my TLS certificates workflow but still use DNSSEC. It is fine.
DNSSEC has this nice concept called DANE (see below) in which one inserts special records in their zones with the signature of the certificates for the various services n-one is running run (mail, web, imap and so on). That way, you do not need to trust a large set of Certificate Authorities (CA) to do the right thing.
We have seen in the past many of them screwing the process of validating ownership of a given domain before issuing certificates. There are ways of protecting this stuff too (The CAA record being a recent one) but still, your average certificate store has litterally hundreds of different CA. Unless you manually remove every single one you do not trust, you trust all.
The catch
DNS is hard. That’s a fact. I’ve seen so many people (including me of course) breaking their zone files for some reason (misplaced “;”, not changing the serial number, etc.) so yeah, I know. Been there, done that.
DNSSEC is a great thing but yes, it does complicate some things, mainly key management and rollover. Day-to-day operations are not really changed, especially if you have a decent IPM product (COTS or homegrown) to deal with zone management. So yes, DNSSEC is complicated too.
DANE can be used to validate that the mail server you are connecting to is the right one. DANE does not care whether you are doing web stuff, mail stuff or anything stuff, as long as you are dealing with TLS certificates and validation. You just put a TLSA record with the hash of your public key/certificate/both and the client on the other side can easily check that. And you know that this data has not been modified (signatures and all that.)
but
Many people find DNSSEC too complicated, especially when they have thousands of hostnames, changing frequently (think of Content Delivery Networks or massively parallel infrastructure), they do not want to deal with the cryptographic aspects of DNSSEC, its key management part and stuff.
The solution (?)
What else if not our great (NOT!) friend called Not Invented Here (NIH) syndrom?
The nice thing about DANE is that it involves only two entities that are already talking together, the mail server sending mail and its DNS resolver, because everything it needs for DANE is in the DNS. Must be too easy, right?
So some guys at Microsoft, Google and Yahoo! (you know, the biggest mail providers, yadda yadda yadda) invented something that does not need DNSSEC to operate but (wait for it)…
…add a webserver to the mix!
The MTA, in addition to fetching the MX & associated A records, has to
- ask the receiving DNS a special TXT record, hosted in a special zone and cache it
- contact a webserver on a specific hostname for a file
- parse the file and check its content against what it already got in the DNS
- connect and send the mail
Sounds easy, no?
Wrong
It adds yet another entity (the website) to contact (and timeout with sometimes), yet another completely specific cache for the sending side.
But, that’s not all.
On the receiving site, you will need a specific website (mta-sts.DOMAIN) with its own certificate (unless you use a wildcard) to host a specific file with a specific format (albeit not in a new location, .well-known has been accepted as a place to put stuff for some time now).
Oh and of course, everytime you change you policy (the aforementioned file), you need to record the change in the DNS.
Oh and of course, MTA sending to a subdomain of DOMAIN must not use the policy of DOMAIN and you must install a policy in subdomains too.
And do not start me on the process of delegating the policies (something you may want to do if you have a lot of them) to another host/entity. If you delegate the policy for example.com to example.net, not only you have to use a CNAME to redirect the names in the DNS but the certificate must remains the same (i.e. example.net must answer with a example.com certificate even hosted on foobar.example.net).
BTW it does less than DANE because in the policy you specify only the MX, not the signatures of the certificates.
Nice way to keep the lucrative (a bit less now thanks to Let’s Encrypt) business of certificates and CA, eh?
All this crap just to avoid DNSSEC whereas they could use their resources and time to properly install & manage DNSSEC.
Fuck this. I might be getting too old for this shit.
Read the draft below and be enlightened (or not).
Stéphane Bortzmeyer has its own analysis — a bit more technical than what you are reading, see below (in French).