Deploy360 21 August 2015

Even more DANE/DNSSEC/TLS email testing from Go6lab

By Jan ŽoržFormer Operational Engagement Programme Manager

DANEAfter my two previous posts about deploying DANE/DNSSEC in the go6lab and then testing the top 1 million Alexa domains for DNSSEC, DANE and TLS, I got some additional questions about more tests and requests for help from one IDN TLD provider from Egypt (I’ll write about that when the deployment is finished and tested).

One of the more interesting questions was, “If TLSA records are published but not signed, what will postfix do? Ignore the record completely?” Our first impression is that it should (as it’s defined in the RFC), but let’s test what the real world situation is. Remember, the goal of DANE verification in the email world is to prevent sending emails to malicious server-in-the-middle, that could be trying to intercept your emails.

We have several domains in the lab for testing, one of them with DNSSEC left unsigned on purpose. Go6lab.si and zorz.si are signed, ncc.si is not signed. We also set up an email server that is TLS-enabled (postfix 3.0.1) and is in a signed zone – mx.go6lab.si.

So, let’s test three things:

  • send an email to an address that is in a not-signed zone, but the MX for that zone points to a record that is in a signed zone and has valid TLSA
  • send an email to an address that is in a signed zone, but MX points to a record in a not-signed zone and has TLSA record (also not-signed)
  • verify if malformed not-signed TLSA prevents sending of email to wrong mail server

For the first case we chose to send email to [email protected] (not-signed zone), pointing MX record for ncc.si to mx.go6lab.si (signed, with TLSA). The result was “Anonymous TLS connection established to mx.go6lab.si[2001:67c:27e4::23]:25:”. What’s happening? Remote mail server that has DANE and DNSSEC capability figured out that MX record for zone ncc.si is not signed, so completely aborted the verification process at the very beginning as it can’t possibly trust the content of MX record, served by ncc.si zone.

In the next scenario, we sent email to [email protected] (signed zone), pointing MX record to mail.ncc.si record (not-signed) that has a TLSA. Well, two of them…

_25._tcp.mail.ncc.si TLSA has the valid hash of the certificate that server offers
_25._tcp.mail-bad.ncc.si TLSA has the invalid hash (we just changed the first character of the hash and that makes it invalid)

We also added the “bad” mail A/AAAA record:
mail.ncc.si points to A and AAAA record of mail server that accepts mails for ncc.si and zorz.si.
mail-bad.ncc.si points to same exact A and AAAA records.

We changed the MX record in signed zone zorz.si pointing to mail.ncc.si (unsigned A/AAAA/TLSA records available)

First signs of incoming spaghetti-incident are showing up – checking for TLSA records with dig at our resolvers (unbound) returned no answer until we “mellowed” the DNSSEC validation. Now the resolver returned a TLSA record even if not-signed. At this point the whole experiment already felt completely wrong, but for all those who would like to repeat it – set the below value in unbound.conf and you’ll mellow down the strictness of DNSSEC checking:

val-permissive-mode: yes

Sending email to [email protected] through our test sending-mail server results in:
Untrusted TLS connection established to mail.ncc.si[2001:67c:27e4::beee]:25:

Of course, the certificate there is self-signed and by definition postfix completely ignored the DANE verification, as mail.ncc.si is in not signed zone – and having TLSA doesn’t help much.

Next thing to try is to change the MX record for signed zone zorz.si to mail-bad.ncc.si that has invalid TLSA hash record, but since it’s unsigned we would suspect that it doesn’t matter anyway as it will skip it and not prevent sending email to somebody in the middle, that is trying to intercept our emails.

The result was predictable:

Untrusted TLS connection established to mail-bad.ncc.si[[2001:67c:27e4::beee]:25:

As soon as DNSSEC trust chain is broken, DANE verification is completely ignored, and that goes along the lines with what is explaind in Postfix TLS readme (DANE TLS authentication section):

http://www.postfix.org/TLS_README.html

Conclusions: DANE for email works as expected and as standardized, it just needs to be deployed in right way by people who understand what they are doing. If you break the chain of DNSSEC trust, DANE is completely useless as it needs to trust all components of the mix – MX record, A/AAAA records and TLSA record.

P.S. Want to get started with DNSSEC and DANE, please visit our Start Here page to find resources to help!

Disclaimer: Viewpoints expressed in this post are those of the author and may or may not reflect official Internet Society positions.

Related articles

Improving Technical Security 15 March 2019

DNS Privacy Frequently Asked Questions (FAQ)

We previously posted about how the DNS does not inherently employ any mechanisms to provide confidentiality for DNS transactions,...

Improving Technical Security 14 March 2019

Introduction to DNS Privacy

Almost every time we use an Internet application, it starts with a DNS (Domain Name System) transaction to map...

Improving Technical Security 13 March 2019

IPv6 Security for IPv4 Engineers

It is often argued that IPv4 practices should be forgotten when deploying IPv6, as after all IPv6 is a...