🪲: DANE TLSA support looks far from correct

[mdecimus]

What happened?

A quick read of the code suggests the following defects:

• When TLSA records include both the DANE-EE(3) usage and DANE-TA(2), it appears that BOTH must match
  • That is, if no usage DANE-EE(3) records match, the DANE-TA(2) records are not considered
  • When only DANE-TA(2) records are published, the chain is verified using WebPKI trust anchors, and then required to match one of the DANE-TA(2) records, which is PKIX-TA(0) semantics, not DANE-TA(2).
  • It is unclear how TLSA base domain is determined, when DANE is in effect, the TLSA base domain should be used as the SNI hostname and should also be the hostname checked when verifying DANE-TA(2) chains, which need not be anchored at a WebPKI CA, so DANE-TA(2) verification needs to override the trust-anchors to enable anchoring the chain at a possibly non-self-signed (subsidiary/intermediate) CA, or a private root, or a WebPKI root, ... And the TA is almost always in the form of a hash, so the verification logic is custom code, distinct from the standard PKIX logic.
  • When both DANE-EE and DANE-TA records are published, the TLSA base domain is ignored for matching the EE cert, but MUST be verified when matching issuer certs.
    • A strictly correct implementation would also allow the nexthop (typically recipient) domain to match if TLSA base domain does not. And also the MX hostname if distinct from the TLSA base domain (when that is found by CNAME chasing).

How can we reproduce the problem?

I can reproduce the problem by doing the following steps:

Version

v0.13.x

What database are you using?

None

What blob storage are you using?

None

Where is your directory located?

None

What operating system are you using?

None

Relevant log output

Code of Conduct

• I agree to follow this project's Code of Conduct

[vdukhovni]

Please reach out if you have questions, by email if these need not be persisted here.
The key observations are:

• Validation of DANE TLSA records succeeds whenever any one of the published TLSA records matches, so there's no dependence of validation of some records on the presence of absence of others.
• Usage DANE-TA(2) record validation differs from "normal" PKIX chain construction:
  • All the certificates must be presented by the remote server, there's no need to look in the local trust store
  • A chain needs to be constructed from these, just long enough to match one of the TLSA records
  • Issuer signatures and expiration dates need to be checked for all the certificates except the TA.
  • The constructed chain can be anchored by an intermediate CA which (perhaps just its key) matches a TLSA record
  • With DANE-TA(2) SPKI(1) Full(0) records the TA is a raw public key, it can be used directly to verify a chain certificate, so the chain is then anchored by a certificateless public key.
  • The DNS-ID reference identifier to match against the DNS-ID presented identifier in the EE certificate is one of:
    • The TLSA base domain[1],
    • The MX hostname if different
    • The nexthop domain from which the MX host was obtained (if different from the MX hostname)
• It is important to NOT look for TLSA records when the zone of the MX host is insecure, otherwise (see RFC7672) you risk failure to deliver mail to domains whose non-DNSSEC nameservers mishandle requests for novel to them RRtypes.
• It is of course otherwise essential to not be subject to downgrade attacks. Failure to resolve the TLSA records to other than non-empty RRSet, NODATA, or NXDOMAIN, MUST result in avoiding that MX host, and trying another if available, or deferring the delivery. Attempts to obtain TLSA records should happen prior to connection establishment, do not connect to hosts which ultimately have to be skipped because TLSA lookup SERVFAILed or timed out, ...

[1] The TLSA base domain can differ from the MX hostname when the MX hostname is the start of a non-empty CNAME chain in which all the CNAME RRs are DNSSEC-signed (entire CNAME chain gets AD=1 from a trusted validating resolver) and the last name has DNSSEC-validated A and/or AAAA records. If at that final fully expanded name TLSA records are found, that is the TLSA base domain, instead of the original MX hostname.

Mind you, the vast majority of MX hosts are not aliases, and even among those that are, very few publish TLSA records at the final CNAME target. It may be a reasonable choice to only ever check for TLSA records at the unexpaneded MX hostname, leaving a very small number of domains unsupported (for DANE).

If there are no TLSA records at the final CNAME target, or the CNAME chain is not signed at every step (so the final name is untrusted) you then need to check whether the zone at the start of the CNAME chain is signed, this can be done by issuing a query of type CNAME, which should return a validated response for just the initial CNAME if the zone is signed, and an "insecure" (AD=0) response when the zone is not signed. It is also OK to get a validated NODATA response (the CNAME disappeared while you're looking), an NXDOMAIN response implies the MX host no longer exists, move on...

[vdukhovni]

So a correct implementation needs to do a few things right:

• Implement a downgrade-resistant algorithm for locating the TLSA records when they are published
• Skip MX hosts for which that algorithm tempfails
• Enforce DANE when that algorithm definitively finds TLSA records.
• Fall back to non-DANE behaviour when that algorithm definitively finds no TLSA records, or that the zone in which they are to be found is unsigned!

One TLSA records are in hand, implementing support for DANE-TA(2) means doing some of the chain construction and validation directly, when the chosen TLS/X.509 library lacks DANE support. My suggestion is to work with the Rust X.509 library maintainers to add support for DANE-based certificate chain validation with given TLSA records, as is e.g. the case with OpenSSL. This should not be left to (each) application to implement.

But it may be reasonable for that to first be prototyped in an early adopter application, with a view to ultimately merge the feature into RustTLS/X.509.