Use DNSSEC/DANE chain stapled into TLS handshake in certificate chain validation
Categories
(Core :: Security: PSM, enhancement)
Tracking
()
People
(Reporter: saa, Unassigned)
References
Details
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:143.0) Gecko/20100101 Firefox/143.0
Steps to reproduce:
This is former Bug 672600 listed as wont fix, given the following information
n the recent ICANN Registrations Operation Workshop 30th September 2025, the following data was shared about DNSSEC Validation Rates
Region / Rate / Increase since 2023
Asia 32% +4%
Oceania 54% +11%
Africa 46% +15%
Americas 37% +4%
Europe 48% +8%
DNSSEC is being used, its growing and support is required within the browser, this of course would require a change on DANE support
https://regiops.net/event/14th-registration-operations-workshop-row14-online-event
Actual results:
This could have been resolved years ago
Expected results:
Full DNSSEC and DANE support is now required
|
||
Comment 1•9 months ago
|
||
Why is it important that Firefox support this feature?
|
||
Comment 2•9 months ago
|
||
(In reply to Dana Keeler (she/her) [:keeler] from comment #1)
Why is it important that Firefox support this feature?
Because it would be the first widely used browser that could validate certificates with using DANE TLSA records, thus offering an alternative to the current PKI mess, that is CA-signed certificates.
There are plenty of projects that will create TLSA records to be used for certificates, exactly for this reason. Shameless plug, I've created one such project too. As far as I know, at the time of writing this it's only maybe some MTAs and XMPP clients/servers use them.
It would be actually nice to have this technology in the web space, thus not having to deal with the current status quo, where you have to have a central-authority-signed certificate if you want browsers to load your page without warnings and blockers. Imagine this arriving to Thunderbird too.
What's even more ridiculous is, Cloudflare that is de-facto MitM, will make the aforementioned certificate check 'just pass', whereas Cloudflare is able to see the unencrypted traffic en route. Not everyone is a big fan of that.
We've been asking for this for at least a decade, imo.
|
|
||
Comment 3•9 months ago
|
||
(In reply to László Károlyi from comment #2)
Because it would be the first widely used browser that could validate certificates with using DANE TLSA records, thus offering an alternative to the current PKI mess, that is CA-signed certificates.
What precisely about the current state of the webPKI is concerning? How would Firefox supporting DANE address those concerns?
There are plenty of projects that will create TLSA records to be used for certificates, exactly for this reason. Shameless plug, I've created one such project too. As far as I know, at the time of writing this it's only maybe some MTAs and XMPP clients/servers use them.
Do those projects not work with the webPKI as-is?
It would be actually nice to have this technology in the web space, thus not having to deal with the current status quo, where you have to have a central-authority-signed certificate if you want browsers to load your page without warnings and blockers. Imagine this arriving to Thunderbird too.
Are DNS registrars not also central authorites?
What's even more ridiculous is, Cloudflare that is de-facto MitM, will make the aforementioned certificate check 'just pass', whereas Cloudflare is able to see the unencrypted traffic en route. Not everyone is a big fan of that.
Whether or not websites choose to use that feature seems orthogonal to me. Even if Firefox supported DANE, many sites would still use Cloudflare's TLS termination.
We've been asking for this for at least a decade, imo.
That alone is not a persuasive reason to support this feature.
Interestingly when the bug was open I referenced the original bug request 672600 which was removed from title. As I understand Google did support DNSSEC but dropped support because DNSSEC was note being used. Clearly that situation has changed. There were Firefox plugins which allowed DNSSEC/DANE validation but Firefox was altered so that this functionality was no longer available. See https://www.dnssec-validator.cz/
The DNSSEC/TSLA validator performed the following
DNSSEC/TLSA Validator allows you to check the existence and validity of DNSSEC signed DNS records. DNSSEC Validator shows whether the domain name is DNSSEC-signed. It also checks whether the browser is connecting to the correct IP address assigned for this domain name. If a valid DNSSEC chain related to the domain is found the plug-in will also check for the existence of TLSA records. TLSA records store hashes of remote server TLS/SSL certificates. The authenticity of a TLS/SSL certificate for a domain name is verified by DANE protocol (RFC 6698). DNSSEC and TLSA validation results are displayer by using several icons. Additional explanatory texts are shown in the page’s address bar (MF, GC and OP), in a separate tool bar (IE) or toolbar buttons (AS). Clicking on a given icon symbol reveals more detailed information.
key features (short list)
DNSSEC Validator checks the existence and validity of DNSSEC-signed DNS records for domain names and it also checks whether the browser is connecting to the correct IP addresses assigned for these domain names.
TLSA Validator attempts to perform a validation of TLSA/PKI pair according to the DANE protocol.
TLSA Validator can interrupt HTTPS request when the server certificate doesn't correspond with obtained TLSA records (MF only in synchronous mode, AS).
DNSSEC/TLSA Validator is not dependent on an external validating resolver for its function.
DNSSEC/DANE extends security by allowing a user when browsing the internet to authenticate, validate and verify the DNS information is correct and check that the actual browser destination address is correct, DANE also provides the function to check that the PKI CA public certificate has signed the certificate being present, in addition it can also check the endpoint server certificate against a TLSA resource record. So if both TSLA records for the endpoint and PKI CA public certificates are stored as TLSA records it enabled DNS Administrator to add an layer of protection for potential or existing customer when accessing their domain.
Of course there is the added benefit that using DANE, it is possible for a DNS Administrator to add an Organisations Self Signed CA public certificate as a DANE type 2 record allowing them to also provide an endpoint certificate signed by the self signed CA as a DANE type 3 resource record. This would allow for a DNS domain based certificate PKI infrastructure.
Why has DNSSEC validation reached the levels it has because it is only way to provide authenticated, validated and verified DNS resolution, DoH and DoT only hide the DNS communication between the client and DNS resolver.
The issue is not why DNSSEC/DANE support should be added but why given the evidence that DNSSEC validation is wide spread and rising that a web browser does not support it. GDPR regulations require "Security by design and default" which probably explains why DNSSEC validation rates are increasing as it improves security except when using a web browser?
|
|
||
Comment 5•9 months ago
|
||
(In reply to Dana Keeler (she/her) [:keeler] from comment #3)
I've already said my piece about why DANE+DNSSEC would be one crucial improvement to have.
If this article doesn't manage to convince you based on its merits, I don't know what will:
https://blog.technitium.com/2023/05/for-dnssec-and-why-dane-is-needed.html
With that, I consider my part done in this debate. All I ask is, don't hold the development of this feature back.
|
||
Comment 6•9 months ago
|
||
(In reply to László Károlyi from comment #5)
If this article doesn't manage to convince you based on its merits, I don't know what will:
https://blog.technitium.com/2023/05/for-dnssec-and-why-dane-is-needed.html
That article says "The most useful feature of DANE that PKI cannot provide is that it protects email by ensuring that SMTP protocol uses TLS preventing downgrade attacks." Which is an irrelevant feature for a browser.
With that, I consider my part done in this debate. All I ask is, don't hold the development of this feature back.
The feature simply isn't adding significant enough value to the browser for us to spend scarce engineering cycles on.
|
|
||
Comment 7•9 months ago
|
||
(In reply to Lars Eggert [:lars] from comment #6)
(In reply to László Károlyi from comment #5)
If this article doesn't manage to convince you based on its merits, I don't know what will:
https://blog.technitium.com/2023/05/for-dnssec-and-why-dane-is-needed.htmlThat article says "The most useful feature of DANE that PKI cannot provide is that it protects email by ensuring that SMTP protocol uses TLS preventing downgrade attacks." Which is an irrelevant feature for a browser.
That's just one part of it. If you give it a thorough read, it makes plenty of arguments as to why and how DNSSEC+DANE can be implemented in browsers without much effort (DNS resolvers are already a part of browsers), and also how it can add immense value.
The feature simply isn't adding significant enough value to the browser for us to spend scarce engineering cycles on.
I'd argue with the first part, but can understand the second.
|
|
||
Comment 8•9 months ago
|
||
As far as I can tell, the argument for DANE is that instead of trusting 100s of CAs, you only need to trust the entity that signs for your TLD. Assuming for the moment that there are no downsides to this, merely adding support for DANE won't actually achieve this goal, because of all of the sites that will still require traditional PKI. Practically speaking, I don't see a path forward to a world where Firefox doesn't trust those 100s of CAs and only relies on DANE. Furthermore, doing so would abandon all of the work we've gained in terms of transparency, revocation (which relies on transparency), and improvements in the certificate issuance space.
|
||
Comment 9•9 months ago
|
||
(In reply to sophie from comment #4)
Interestingly when the bug was open I referenced the original bug request 672600 which was removed from title.
It was moved to the more appropriate "see also" field. Hardly interesting.
There were Firefox plugins which allowed DNSSEC/DANE validation but Firefox was altered so that this functionality was no longer available.
The web extension architecture change had nothing to do with DNSSEC/DANE.
Why has DNSSEC validation reached the levels it has because it is only way to provide authenticated, validated and verified DNS resolution, DoH and DoT only hide the DNS communication between the client and DNS resolver.
DoH and DoT are independent of DNSSEC, solving different problems. You could choose a DoH provider that promises to enforce DNSSEC, or you could use DoT to connect directly to the server you get the DNSSEC info from so it's not sent in the clear. They are unrelated other than being "security-related" features.
Description
•