User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0 Build ID: 20150826044534 Steps to reproduce: Using current Firefox ESR 38.2.1, visit a https website which uses a self signed certificate.and has valid TLSA Records protected by DNSSEC according to RFC6698 and RFC7218, e.g. https://www.udin.ch. Actual results: Firefox comes up with "This connection is untrusted" because it validates against the Trusted Root CAs only. Expected results: Firefox should prefer and honor DNSSEC-validated TLSA before falling back to "classic" Root CA TLS verification. Please implement the RFCs 6698 and 7218.

See also bug 672600 (and in particular bug 672600 comment 38). (Side-note: This isn't quite a duplicate, as that bug is specifically about using stapled DANE records, whereas this bug appears to be about actively fetching the records.)

Is this bug still an issue after the above comment?

Yes. Firefox ESR 38.6.1 still does not use DANE nor TLSA. The goal is the verification of a certificate against a DNS record instead of checking against Root CA certificates. The procedure is outlined in various RFCs (see https://datatracker.ietf.org/wg/dane/documents/).

I will mark this bug as new since it is an enhancement.

Why are we seeing so low priority on this enhancement ? Wouldn't it make sense that browser would have this kind of functionality nowdays ?

Here's the long version why I think this isn't having a higher priority: http://byuu.org/other/ssl/ Short version: Any change that badly affects a middleman

Here's the long version why I think this isn't having a higher priority: http://byuu.org/other/ssl/ Short version: Any change that badly affects a middleman business that causes them to get less money in the long term will be greatly opposed.

I think you are not right here. Let's Encrypt affected these middle man already badly. There came already big movement in the market for domain validated certificates. Best offer as far I know is actual a thee years valid certificate with 20 domains for free. That the CA system in general is broken and not trustworthy I think we all agree. Remember the honest Achmed: https://bugzilla.mozilla.org/show_bug.cgi?id=647959 But EV certificates still needed in some cases and have their right to exist. That DANE is working there is no doubt. I have enabled DANE now since over a year on all my mail servers. Without any negative side effects. And the log entries "Verified TLS connection established to..." are simply looking good :). And yes: The DANE implementation is honouring self signed certificates DANE verified as trustworthy. The number of DANE secured mail systems is slowly but constantly rising thanks to the effort some postfix guys, mailbox.org and posteo.de have shown here. I have no idea how Mozilla is ranking the importance of enhancements but one parameter might be: How many users are benefiting from it? As long the number of domains with DNSSEC and TLSA records is small the number of users benefiting from it is small the resources are used for other things. Even if an enhancement like DANE would be quite simple to implement. The classic chicken - egg problem? The problem is somehow DNSSEC which is mandatory for DANE/TLSA. As far I could see DNSSEC is for many domain owners not a priority. Or they even don't know what it is and why it is important. They either have no access to their DNS or don't have the knowledge at all. Or they are afraid: DNSSEC isn't forgiving any mistakes. Small mistakes and you are offline. It involves also more parties. The DNS admin, the webmaster, postmaster, each one where a specific certificate is used. Everything must be done in time in a specific order. A mistake: Offline. Automated tools are here missing. And as long widely used admin tools like cPanel or Plesk (yes, they are IMHO ****, but many using it) are not supporting this with a simple mouse click the number of domains fulfilling the requirements for DANE will remain small. Out of my experience the most admins having not a real idea what DNS is. It is there and we need it for something somehow. But how it is really working and what you can do with it: Absolutely no idea. For DANE/TLSA DNSSEC is mandatory. So you should start and securing your domain with DNSSEC and providing TLSA records before complaining. But I agree with you: DANE should become a higher priority. Header key pinning was implemented. And IMHO it is broken by design. It presumes the first connection was not intercepted. With DANE I would have a third party in the verification process. Trust is good, control is better. DANE would offer exactly this needed control. Through an independent system and protocol I can verify the certificate, the CA, HPKP etc. As long the DANE verification is successful the OCSP (also broken by design, is not scaling and stapling is only a crutch for this broken system) queries can get a lower priority. DNS is working, performing and scaling. Not a single of this systems is perfect or good enough. But combined they would be a serious security improvement.

I'm pretty sure that the only flavor of DANE we're going to do is the TLS-stapled one specified being worked in Bug 672600, so I'm closing this one as a duplicate of that one.