DANE vs MTA-STS for secure SMTP transport

Research on implementing and testing DANE (DNS-Based Authentication of Named Entities) has been ongoing and frankly, disturbing. One of the most interesting aspects of DANE is that you do not need to involve third party certificate authorities for the x509 certificates used in the protocol. The CA/B Forum, which is comprised of representatives from the certificate authorities and major web browser platforms, has their own competing standard to DANE. It is called MTA-STS or SMTP MTA Strict Transport Security. And guess what?… their standard literally doubles down on the existing and broken certificate authority model.

The problem(s) with the existing CA (certificate authority) model.

The first problem is the whole idea that hundreds of “trusted” CAs world-wide will always do the right thing when issuing certificates. Just look at the mess of “trusted” root certificates that ship with your web browser. Any CA in the world can issue a certificate for your namespace to anyone they choose. Thus we end up with the whole Certificate Authority business being at risk of whichever Certificate Authority has the worst security policy (a.k.a. weakest link in the chain) which is an absurd notion of security. CAA (Certificate Authority Authorization) is a DNS-based attempt to let namespace owners whitelist only certain certificate authorities as a DNS record, but seriously, if we are going to use DNS records why not just cut out the certificate authorities altogether? Then they can no longer be a weak link in the chain as they are no longer a part of it. Bad-actor CA’s do exist, they are not some hypothetical scenario… hello StartCom.

The second problem is that it costs money to get these certificates from certificate authorities. Let’s Encrypt is the only exception, but their certificates are so short lived that you must automate and script their renewal and roll them into your applications the same automated way. It isn’t the easiest thing in the world to get working correctly. There is also a limit to the number of certificates they will issue you for free. Complexities aside, the money here is the real issue. Implementing MTA-STS requires not one, but at least two, certificates from a certificate authority. Your mail server needs one and you must run a separate secure web server to serve up a JSON policy document in a specific sub-domain of your namespace. If you run email over several domains you need to setup several secure web-servers with different certificates to serve that same JSON policy document and all of those need a certificate signed by a trusted certificate authority.

This is a great policy, if your business is selling certificates. Think about what it means from a free speech perspective. Eventually if you are not running MTA-STS you will not be able to email anyone on the broader internet. Sure, your Gmail and Hotmail will work just fine, until you try to communicate with someone outside of that ecosystem. MTA-STS is a de-facto tax on Internet speech. Unless you pony-up the certificate fees or submit to the “community rules” of a social-network platform, your speech doesn’t count. For me, to be MTA-STS complaint I will need to buy $400 worth of certificates a year (cheapest trusted certs from a certificate authority I could find on internet that were not Let’s Encrypt).

MTA-STS Basics

MTA-STS Process Flow

  1. Mail Client (MUA) sends email to sending MTA (Mail Transfer Agent)
  2. Sending MTA asks its DNS resolver to find the receiving MTA’s MTA-STS policy
  3. DNS resolver queries the authoritative DNS server for the policy record at a “well-known” subdomain.
  4. Authoritative DNS server returns a TXT record of the policy version number
  5. DNS resolver returns the MTA-STS policy version number to the sending MTA
  6. Sending MTA now sends an https request to a “well-known” sub-domain address in the receiving domain to get the content of the MTA-STS policy from a secure web-server
  7. The secure policy web-server returns the actual MTA-STS policy to the sending MTA in the form of a JSON document
  8. The sending MTA issues a STARTTLS session with the receiving MTA
  9. The receiving MTA sends its public CA-signed certificate to the sending MTA
  10. If conditions are met, email is transferred over secure transport
    • The JSON ID numbers from the authoritative DNS and policy web-server match
    • The JSON document was retrieved with a secure connection and validates to a valid and browser trusted CA-root-certificate
    • The receiving MTA’s certificate validates to a valid and browser trusted CA-root-certificate
  • MTA-STS does not require DNSSEC, but recommends it.
  • MTA-STS requires x509 certificates validate to a root-CA-certificate
    • no self-signed or snake-oil certificates
  • MTA-STS requires an HTTPS server to serve the policy JSON document.
    • no self-signed or snake-oil certificates here either
  • MTA-STS policy change requires coordination of DNS, HTTPS JSON policy document, and SMTP
  • MTA-STS relies on trust in every certificate authority in the world always doing the right thing.

DANE and DNSSEC Basics

DANE Process Flow

  1. Mail Client (MUA) sends email to sending MTA (Mail Transfer Agent)
  2. Sending MTA asks its DNSSEC resolver for TLSA records for how it is planning to connect to the receiving MTA. (Port 25, using TCP in this example)
  3. DNSSEC resolver queries authoritative DNS server for TLSA records
  4. The authoritative DNS server for the receiving MTA replies with either the public key or a SHA hash of the receiving MTA’s public key (probably a hash since hashes are much smaller than whole RSA public keys)
  5. The DNSSEC resolver replies to the sending MTA with the TLSA record containing the hash of the receiving MTA’s public key
  6. The sending MTA issues a STARTTLS session with the receiving MTA
  7. The receiving MTA sends its public certificate to the sending MTA
  8. If conditions are met, email is transferred over secure transport
    • The DNSSEC queries for all A, AAAA, MX, NS, and TLSA records must return valid all the way back to the root zone.
    • The hash of the receiving MTA’s public key must match the same hash contained in the authoritative DNS server’s TLSA response received in 5.
  • DANE requires DNSSEC
  • DANE allows for “self-signed” certificates
    • If you can add or modify TLSA records for a domain and establish DNSSEC DS records for a domain to make DNSSEC work then you must have control over that domain
  • DANE policy is changed by changing TLSA record in DNS
  • DANE certificate rollover needs to be coordinated with DNS TLSA record roll.
  • DANE relies on DNSSEC chain of trust.
    • Rolling expiring DS keys can be complex.

Where do you put your trust?

It all boils down to what do you trust more. DNSSEC and DANE, used together, provide just as much validation of domain control as a certificate authority can validate. MTA-STS puts the trust in the certificate authorities to replicate and do what DANE and DNSSEC together already do. Certificate Authorities do still have an important role to play on the Internet. There are still plenty of validation opportunities beyond domain validation that need to occur. Extended Validation (EV), Organizational Validation (OV), and Personal Authentication certificates are still important and add value on top of simple Domain Validated (DV) certificates. At this point though there is no good reason to continue insisting that certificate authorities play any role in domain validated certificate issuance. DANE and DNSSEC give us all the domain validation functionality of a certificate authority. The ONLY reason to continue with requiring certificate authorities involvement in DV certificate issuance is to limit free speech on the internet by requiring a fee to participate in the community.

It should also be noted here that having a public key signed by a certificate authority does not make the encryption stronger or the connection any more secure. My self-signed keys use the same encryption (and usually stronger signing hashes) that would be used with or without a CA signing my public key.

Welcome back to reality…

Truth is ~95% of the time my email server is talking to Google. The masses have already put their trust in a shepherd that has done nothing more than proclaim its own benevolence. So whatever Google does I will have to do too. My other choice is to just shut it down, submit, and get a Gmail account. If you look at the top of the IETF proposal for MTA-STS you see two dudes from Google, Inc. right there on top.

DANE is being more widely deployed in Asia and Europe.

So really, I guess I’ll be implementing both DANE and MTA-STS and then letting the sending MTA choose to use either one or none.