DANE verification broken in multiple ways even on cursory inspection.

[vdukhovni]

• Trust manager sometimes uses hostnames insecurely derived from reverse IP -> name lookups.
• TLSA CNAME indirection is not supported
  • Apart from performing requisite additional CNAME chasing lookups, would require validation of security status of each CNAME "hop" along the way
• Usages PKIX-TA(0) and DANE-TA(2) are not handled correctly, the matching is performed against the leaf certificate!
  • For DANE-TA(2), the chain from the trust anchor to the leaf needs to be constructed and checked, without reliance on the default WebPKI validator!
  • For PKIX-TA(0), the PKIX chain needs to be built first, with a check that the DANE constraint is met by an element of that chain.
• Digest algorithm agility (recommended, but not presently critical) is not implemented.

This implementation is sufficiently naïve and incomplete to warrant strong warnings that the code SHOULD NOT be trusted to avoid either false positives or false negatives. It is still an early prototype not ready for primetime.

[Flowdalic]

Thanks for your feedback Viktor.

I think it would be sensible to categorize the points you mentioned in "security-related" and "missing functionality" ones.

If I am not mistaken, and please correct me if I am wrong, from the four points you bring up, CNAME chasing and digest algorithm agility belong into the "missing functionality" category.

That remaining ones are

1. Trust manager sometimes uses insecurely derived hostnames
2. PKIX-TA(0) and DANE-TA(2) are not handled correctly

Looking at the code, MiniDNS does not support PKIX-TA and DANE-TA, in both cases the verification fails, and a warning is logged, noting that this is not (yet) supported. Hence I tend to categorize this as "missing functionality". However, you write that "PKIX-TA(0) and DANE-TA(2) are not handled correctly", which reads differently than my assessment.

Without having had time for a closer look at 1) and 2) and giving it more though, would you mind to elaborate a little bit? For example, some code pointers where the trust manager sometimes uses hostnames in an insecure way would help a lot.

[vdukhovni]

• In the case of DANE, since you don't apply DANE validation when TLSA records appear to be absent, failure to chase CNAMEs is actually a security failure.
• Digest algorithm agility is only important if some day SHA256 proves less secure than SHA512 (or vice versa) and there's no sign of that any time soon, so not a concern at present.
• Well, DANE-TA(2) is a popular choice, and verification failing is not an option. If you're implementing DANE, it needs to be supported.
• PKIX-TA(0) would presumably be popular if/when HTTPS sites start publishing DANE for port 443 and want to augment rather than replace the WebPKI. It should be implemented for any applications that want to do that.

Which brings me to additional points:

• Applications need to be able to specify which usages are appropriate (e.g. just DANE-EE/TA for SMTP, and perhaps just PKIX-TA/EE for some HTTP client)
• And need to be able to specify whether they want hostname checks in DANE-EE(3) (important to avoid UKS attacks in HTTP, but not needed for SMTP).

The current code performs no namechecks for DANE-EE(3), but that turns out to not always be the right thing to do.

Take a look at the OpenSSL DANE documentation for some idea of what sort of tunable parameters might be appropriate.

And this isn't a complete review. The code is not ready, and should not be used.

[vdukhovni]

Also, when DANE validation completes, callers should be able to get at the matching TLSA record, and matching certificate for diagnostic purposes, although a sufficiently fancy logging framework can make some of that less critical, if all they want is to display it to a user or record the information in the log.

[vdukhovni]

More seriously perhaps, also the DNSSEC client does a poor job of validation of denial of existence:

• NSEC/NSEC3 validation does not establish a closest encloser and check that no applicable wildcard records are in scope.
• Denial of existence is based on the answer section being empty, rather than the RCODE (NODATA, NXDOMAIN). Either of these can be accompanied by a chain of intra-zone CNAME RRs, with the status and NSEC chain applicable to the last CNAME target in the chain (starting at the qname).
• When validating a negative response, one must also check that the type bits don't include CNAME, or NS+DS (signed delegation)
• I have not check whether NSEC3 opt-out is handled correctly.
• I did not check whether DNAMEs are supported, or how CNAME chains are validated.

Writing a modern DNS resolver is rather difficult. The concerns are many and subtle. :-(