3

In the scenario with two domain names

  • example.com secured with DNSSEC
  • example.org not secured with DNSSEC

and a mail service running at smtp.example.org:

I want to secure the mail service using TLSA/DANE. Is this somehow possible and can I expect this to work for most DANE aware software?

The idea is to publish a TLSA record _25._tcp.smtp.example.com and a CNAME record smtp.example.com that points to smtp.example.org. The response from the org zone cannot be trusted because it's not DNSSEC secure, but the TLSA record from com can. Is this a reasonable way to enroll DANE for zones that are not yet DNSSEC ready?

Update: I just found this in section 7 of rfc7671:

The complexity of coordinating key management is largely eliminated when DANE TLSA records are found in the Service Provider's domain, as discussed in Section 6. Therefore, DANE TLS clients connecting to a server whose domain name is a CNAME alias SHOULD follow the CNAME "hop by hop" to its ultimate target host (noting at each step whether or not the CNAME is DNSSEC validated). If at each stage of CNAME expansion the DNSSEC validation status is "secure", the final target name SHOULD be the preferred base domain for TLSA lookups.

So in my case the the validation status is not "secure" and the rfc continues with:

Implementations failing to find a TLSA record using a base name of the final target of a CNAME expansion SHOULD issue a TLSA query using the original destination name. That is, the preferred TLSA base domain SHOULD be derived from the fully expanded name and, failing that, SHOULD be the initial domain name.

The client 'should' eventually resolve the initial domain name, but I'm not sure if that actually happens in most cases.

Community
  • 1
Dons
  • 33
  • 5
  • Thanks. 1. Would it make sense in this case to also publish double DANE/TLSA records like you are suggesting on http://imrryr.org/~viktor/ICANN61-viktor.pdf#page=20 ? 2. Besides, the used certificate probably won't match smtp.example.com. I guess that doesn't really matter, because sending mail servers usually don't match the server name against the certificate. Correct? – BartK Apr 10 '18 at 21:11

2 Answers2

5

The configuration:

example.com. IN MX 0 smtp.example.com. ; AD=1
smtp.example.com. IN CNAME smtp.example.org. ; AD=1
smtp.example.org. IN A 192.0.2.1 ; AD=0
_25._tcp.smtp.example.com. IN TLSA 3 1 1 e3b0...b855 ; AD=1

Will yield DANE-secured TLS with at least some DANE implementations, e.g. Postfix. However, this may not work in all cases, for two reasons:

  1. CNAMEs violate the RFC requirement that the exchange field of the MX record be already canonical and not a CNAME (see https://www.rfc-editor.org/rfc/rfc5321#section-5.1), therefore, though I don't know of any MTAs that disallow CNAMEs here, they'd be compliant with the standard if they did. However, in my survey of (today) 4,244,642 DNSSEC-signed domains that have MX records, I find 1,432,478 distinct MX hosts of which 21,262 are CNAMEs (serving 34,886 domains), and apparently not having problems. So in practice CNAMEs in MX records appear to work.
  2. More importantly, https://www.rfc-editor.org/rfc/rfc7672#section-2.2.2 explains that TLSA lookups should be skipped when the MX host name lies in an unsigned zone, as evidenced by the security status of its A/AAAA records. When no CNAMEs are involved this is simple, and implementations are unlikely to mishandle this case. When the MX hostname is a CNAME into an insecure zone, I expect that some implementations (e.g. I believe Exim) will not determine the security status of the initial CNAME, and so (unlike Postfix) will not attempt TLSA lookups in that case.

Figuring out whether the CNAME RR pointing at insecure A records is secure requires a separate CNAME query for the same name, which suppresses recursion in the resolver and returns the security status of the CNAME itself. Exim, and likely some other MTAs may not do that. While RFC7672 says they SHOULD do it, it is rather subtle logic, and likely to be skipped in implementations.

Bottom line, if you really want DANE to work, avoid CNAMEs into insecure domains, and if necessary, publish A/AAAA records in the secure domain that duplicate the A/AAAA records of the underlying host:

example.com. IN MX 0 smtp.example.com. ; AD=1
; smtp.example.com. IN CNAME smtp.example.org. ; AD=0
smtp.example.com. IN A 192.0.2.1 ; AD=1 (cloned from smtp.example.org)
_25._tcp.smtp.example.com. IN TLSA 3 1 1 e3b0...b855 ; AD=1
Community
  • 1
Viktor Dukhovni
  • 66
  • 1
0
  1. Would it make sense in this case to also publish double DANE/TLSA records like you are suggesting on http://imrryr.org/~viktor/ICANN61-viktor.pdf#page=20?

The choice of TLS record types to use for robust key management is a mostly separate issue. So yes, of course, there should probably be at least two records either dual "3 1 1" (current + next) or "3 1 1" + "2 1 1" (server + issuer).

However:

  1. Besides, the used certificate probably won't match smtp.example.com. I guess that doesn't really matter, because sending mail servers usually don't match the server name against the certificate. Correct?

The certificate should match all the MX hostnames used by any domain to direct mail to the server in question. That's what subjectAlternativeName is for in the certificate. While in SMTP matching of TLSA records with certificate usage DANE-EE(3) explicitly ignores the DNS names in the certificate, taking the name binding from the TLSA record in DNS, the same is not true for certificate usage DANE-TA(2). So make sure to list all the requisite names in the certificate.

Viktor Dukhovni
  • 1