Please consider adding support for checking TLSA records via DNS-over-HTTPS as an addition to the deprecated HPKP and (not sustainable) HSTS Preloading. HPKP (basically a certificate whitelist) is considered as deprecated. (bug 1412438) A DNSSEC/DANE chain stapling TLS extension (bug 672600) would have the same pain as OCSP. Either not to be implemented, or not correctly implemented (https://trac.nginx.org/nginx/ticket/812). Firefox 57+ is not compatible with https://addons.mozilla.org/firefox/addon/dnssec-validator/. Chrome is. https://hstspreload.org is not a sustainable solution. It takes months to get included into the latest stable version of all web browsers. Legacy browsers do not get HSTS Preload updates. This forces people to open legacy port 80 for new projects. The list is getting fat: https://searchfox.org/mozilla-central/source/security/manager/ssl/nsSTSPreloadList.inc 38710 webservers are HSTS Preloaded. 185948 mailservers are using TLSA. That's 4.8 times the size of the HSTS Preloading list. https://mail.sys4.de/pipermail/dane-users/2018-April/000446.html I haven't found numbers for port 443, but there are some bots going around and making stats. (Seen on our PowerDNS stats page.) TLSA/DANE is the crucial signal to enforce encryption (bug 1158191). TLSA records are easy to generate as a step of an ACME client. For example by using a DNS server API or by updating a zone file. https://www.hardenize.com/report/perfektesgewicht.de#www_dane Art. 25 EU GDPR (https://gdpr-info.eu/art-25-gdpr/) demands "Data protection by design and by default". Currently, web browsers do not have the same level of (technically enforced) transport security as DANE-validating mailservers (if correctly configured). Web browsers are not State of the Art (legal term) in this point. You did not implement an own dns client for complexity and latency reasons. A DNS-over-HTTPS server does the work and already verifies DNSSEC. Either it could push the TLSA result to Firefox or Firefox asks for it. The benefits of DNS-over-HTTPS would make this more painless from a latency perspective, I think. This would be a killer feature of DNS-over-HTTPS which Europeans usually do not need and especially shouldn't use if the DNS-over-HTTPS server or company is located in a Five Eyes country (we are foreigners from their view): https://en.wikipedia.org/wiki/CLOUD_Act https://en.wikipedia.org/wiki/National_security_letter https://en.wikipedia.org/wiki/PRISM_(surveillance_program) This would protect more connections and would be an incentive for interested persons to opt-in into Firefox' DNS-over-HTTPS feature. At least it would be a way to check TLSA records with Firefox again at all. Used together with Unbound, https://twitter.com/jvehent/status/980548741416587264 seems to be a cool solution.
Bug 1450674 Comment 0 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Please consider adding support for checking TLSA records via DNS-over-HTTPS as an addition to the deprecated HPKP and (not sustainable) HSTS Preloading. HPKP (basically a certificate whitelist) is considered as deprecated. (bug 1412438) A DNSSEC/DANE chain stapling TLS extension (bug 672600) would have the same pain as OCSP. Either not to be implemented, or not correctly implemented (https://trac.nginx.org/nginx/ticket/812). Firefox 57+ is not compatible with https://addons.mozilla.org/firefox/addon/dnssec-validator/. Chrome is. https://hstspreload.org is not a sustainable solution. It takes months to get included into the latest stable version of all web browsers. Legacy browsers do not get HSTS Preload updates. This forces people to open legacy port 80 for new projects. The list is getting fat: https://searchfox.org/mozilla-central/source/security/manager/ssl/nsSTSPreloadList.inc 38710 webservers are HSTS Preloaded. 185948 mailservers are using TLSA. That's 4.8 times the size of the HSTS Preloading list. https://mail.sys4.de/pipermail/dane-users/2018-April/000446.html I haven't found numbers for port 443, but there are some bots going around and making stats. (Seen on our PowerDNS stats page.) TLSA/DANE is the crucial signal to enforce encryption (bug 1158191). TLSA records are easy to generate as a step of an ACME client. For example by using a DNS server API or by updating a zone file. Art. 25 EU GDPR (https://gdpr-info.eu/art-25-gdpr/) demands "Data protection by design and by default". Currently, web browsers do not have the same level of (technically enforced) transport security as DANE-validating mailservers (if correctly configured). Web browsers are not State of the Art (legal term) in this point. You did not implement an own dns client for complexity and latency reasons. A DNS-over-HTTPS server does the work and already verifies DNSSEC. Either it could push the TLSA result to Firefox or Firefox asks for it. The benefits of DNS-over-HTTPS would make this more painless from a latency perspective, I think. This would be a killer feature of DNS-over-HTTPS which Europeans usually do not need and especially shouldn't use if the DNS-over-HTTPS server or company is located in a Five Eyes country (we are foreigners from their view): https://en.wikipedia.org/wiki/CLOUD_Act https://en.wikipedia.org/wiki/National_security_letter https://en.wikipedia.org/wiki/PRISM_(surveillance_program) This would protect more connections and would be an incentive for interested persons to opt-in into Firefox' DNS-over-HTTPS feature. At least it would be a way to check TLSA records with Firefox again at all. Used together with Unbound, https://twitter.com/jvehent/status/980548741416587264 seems to be a cool solution.