Use DNSSEC/DANE chain stapled into TLS handshake in certificate chain validation
Categories
(Core :: Security: PSM, enhancement, P5)
Tracking
()
People
(Reporter: keeler, Unassigned)
References
()
Details
(Whiteboard: [dnssec][psm-would-take])
Attachments
(4 obsolete files)
Updated•13 years ago
|
Updated•13 years ago
|
Updated•13 years ago
|
Comment 1•13 years ago
|
||
Comment 2•13 years ago
|
||
Reporter | ||
Comment 3•13 years ago
|
||
Reporter | ||
Comment 4•13 years ago
|
||
Reporter | ||
Comment 5•13 years ago
|
||
Comment 6•13 years ago
|
||
Comment 8•12 years ago
|
||
Comment 9•12 years ago
|
||
Comment 10•12 years ago
|
||
Comment 11•12 years ago
|
||
Comment 12•12 years ago
|
||
Comment 13•12 years ago
|
||
Reporter | ||
Comment 14•12 years ago
|
||
Comment 15•12 years ago
|
||
Comment 16•11 years ago
|
||
Comment 17•11 years ago
|
||
Comment 18•11 years ago
|
||
Comment 20•10 years ago
|
||
Comment 21•10 years ago
|
||
Comment 22•10 years ago
|
||
Comment 23•10 years ago
|
||
Comment 24•10 years ago
|
||
Comment 25•10 years ago
|
||
Comment 26•10 years ago
|
||
Comment 27•10 years ago
|
||
Comment 28•10 years ago
|
||
Comment 29•10 years ago
|
||
Comment 30•10 years ago
|
||
Comment 31•10 years ago
|
||
Comment 32•10 years ago
|
||
Comment 33•10 years ago
|
||
Comment 34•10 years ago
|
||
Comment 35•10 years ago
|
||
Reporter | ||
Comment 36•10 years ago
|
||
Comment 37•10 years ago
|
||
Reporter | ||
Comment 38•10 years ago
|
||
Comment 39•10 years ago
|
||
Comment 40•10 years ago
|
||
Comment 41•10 years ago
|
||
Comment 42•10 years ago
|
||
Comment 43•10 years ago
|
||
Comment 44•10 years ago
|
||
Comment 45•10 years ago
|
||
Comment 46•10 years ago
|
||
Comment 47•10 years ago
|
||
Comment 48•10 years ago
|
||
Comment 49•10 years ago
|
||
Comment 50•10 years ago
|
||
Comment 51•10 years ago
|
||
Comment 52•10 years ago
|
||
Comment 53•10 years ago
|
||
Comment 54•10 years ago
|
||
Comment 55•10 years ago
|
||
Comment 56•10 years ago
|
||
Comment 57•10 years ago
|
||
Comment 58•10 years ago
|
||
Comment 59•10 years ago
|
||
Comment 60•9 years ago
|
||
Reporter | ||
Comment 61•9 years ago
|
||
Reporter | ||
Updated•9 years ago
|
Comment 62•9 years ago
|
||
Reporter | ||
Comment 64•8 years ago
|
||
Comment 65•8 years ago
|
||
Reporter | ||
Updated•8 years ago
|
Comment 67•7 years ago
|
||
Comment 68•7 years ago
|
||
Comment 69•7 years ago
|
||
Comment 70•7 years ago
|
||
Comment 71•7 years ago
|
||
Comment 72•6 years ago
|
||
Comment 74•6 years ago
|
||
Comment 75•6 years ago
|
||
Comment 76•6 years ago
|
||
Comment 77•6 years ago
|
||
Comment 78•6 years ago
|
||
Comment 79•6 years ago
|
||
Comment 80•6 years ago
|
||
Cloudflare is working on supporting DNSSEC by default:
https://blog.cloudflare.com/one-click-dnssec-with-cloudflare-registrar/
Comment 81•5 years ago
|
||
Hi. Is there any news on DANE/TLSA support on Firefox?
Reporter | ||
Comment 82•5 years ago
|
||
This work is not currently prioritized.
Comment 83•5 years ago
|
||
Please wontfix. It seems $25000 were wasted on this unneeded complexity without useful result.
Nginx doesn't even do OCSP right: The MOSS money would have been better invested to fix it for privacy reasons because Firefox otherwise directly connects to the CA's OCSP server.
We have DNSSEC-verifying DNS-over-HTTPS servers (please reopen bug bug 1450674), otherwise trust-dns could be used for local verification (useful but not required for bug 1500289 + bug 1077323).
Comment 84•5 years ago
|
||
Not sure how this is related to nginx or OCSP. DNSSEC, TLSA and DANE are all about integrity, not privacy.
For privacy reasons it's still worth to operate a local DNS server rather than forwarding all queries to a centralized DoH provider.
Previously the Add-on provided by https://www.dnssec-validator.cz/ was quite popular to solve this gap. There have been no WebExtensions replacement (due the lack of an API). There is only a (poorly maintained) alternatve using DoH. But there is currently no way to validate or visualize DNS responses from a local DNS server in Firefox.
Comment 85•5 years ago
|
||
(In reply to Jan Andre Ikenmeyer [:darkspirit] from comment #83)
We have DNSSEC-verifying DNS-over-HTTPS servers
Which is not every FX's user choice but may deploy instances of resolvers in their network that are handling DNSSEC perfectly well. Except FX is lacking support to interpret relevant responses from such resolver instance.
Comment 86•5 years ago
|
||
This bug was about avoiding to request DNSSEC signatures via DNS.
It's about a workaround: This bug intended add a lot of complexity to web servers, to let them request DNSSEC signatures from DNS servers and to push these cached signatures via TLS extension (like OCSP stapling) down to the client. Only to push and validate TLSA records, not to validate A / AAAA records. This would be a solution for a few large web server projects (even nginx still fails to cache OCSP properly), but nothing everyone could use without having to add all these complexity to their own web server software as well. Anyway, the draft expired 1.5 years ago.
For ESNI (which, like TLSA, also requires a further DNS request) it was decided to simply rely on DoH.
For privacy reasons it's still worth to operate a local DNS server
That's the worst thing you could do: All your plaintext UDP DNS requests to [TLD and domain] name servers leave your ISP's network with your IP attached to it to be able to receive an answer. For privacy reasons, DNS requests should be mixed with ones of a large group of users. That's why it's better to use DoH (or even the ISP's dns server).
Previously the Add-on provided by https://www.dnssec-validator.cz/ was quite popular to solve this gap.
I loved it as well. At the end, TLSA should invisibly work as a whitelist (like HPKP) and cause an error page in case of violation. Web Extensions should be able to show which TLSA records were found by Firefox. The simplest solution for the moment is to rely on DoH (bug 1450674) as well.
Comment 87•5 years ago
|
||
(In reply to Jan Andre Ikenmeyer [:darkspirit] from comment #86)
For privacy reasons it's still worth to operate a local DNS server
That's the worst thing you could do: All your plaintext UDP DNS requests to [TLD and domain] name servers leave your ISP's network with your IP attached to it to be able to receive an answer. For privacy reasons, DNS requests should be mixed with ones of a large group of users. That's why it's better to use DoH (or even the ISP's dns server).
Not if the local resolver instance is leveraging DoT (and utilizing multiple upstream nodes with DNSSEC support), as opposed to single DoH in the browser. Plus the local network instance can cover/serve all clients in such network for any/all DNS queries and not just a single browser instance with a single DoH upstream node.
In addition DoH is not without controversy for many users.
For those reasons advocating DoH as reason as won't fix does not seem valid.
Comment 88•5 years ago
|
||
@sgw has it right about the differing purposes.
- DANE provides a means for an origin to specify which CAs a client should trust for a given domain.
- DoH provides a means for a client to talk to confidentially send and receive DNS requests to a resolver.
DANE has many of the positives and negatives of HPKP. It varies in that it requires name server management, and the private keys involved are those of DNSSEC, which itself has proved difficult for people to manage.
Comment 89•5 years ago
|
||
DoH in no way makes DANE redundant, as the recursor still has no way to validate the CA used. Also, DANE fixes most of problems inherent in the CA-cartel model, being strictly stronger than the latter.
As for HPKP (and HSTS, which is very similar):
- it doesn't protect for the first visit
- provides a cookie-like privacy breach
- proves having visited the given domain if your device is seized
To avoid the two latter problems, you need to disable storing HPKP cookies. This way, every visit is effectively the first, nullifying the protection.
Allso, HPKP can make it impossible for a site operator to recover from a security breach (if the attacker places a malicious HPKP cookie). See bug 1412438.
On the other hand, DANE is stateless thus doesn't negatively affect privacy in any way.
Comment 90•5 years ago
|
||
In addition DoH is not without controversy for many users.
For those reasons advocating DoH as reason as won't fix does not seem valid.
Again, the only purpose of this bug was avoiding local dns requests and avoiding DoH. This bug was not about regular TLSA/DANE, but about a TLS extension replacing it.
If we had bug 1450674 (using DoH like ESNI) you were at least able to connect to your own (local or not local) DoH server without having to wait until Firefox was able to make regular DNS requests (other than A/AAAA) for ESNI (bug 1500289) and TLSA/DANE (bug 1077323).
The draft expired 1.5 years ago and the TLS working group removed it from its milestones:
https://mailarchive.ietf.org/arch/browse/tls/?q=dnssec%20chain&gbt=1
https://mailarchive.ietf.org/arch/msg/tls/egpvzZwjYSBj5y9y5uC7wRHgKNA/
Deleted milestone "DANE Record and DNSSEC Authentication Chain Extension for
TLS to IESG".
At IETF103, the WG considered the way forward for draft-ietf-tls-dnssec-chain-extension. Based on the attempts at discussion on the list and the sense in the room, the chairs believe that there is no longer interest in continuing work on draft-ietf-tls-dnssec-chain-extension as a WG document.
Comment 91•3 years ago
|
||
We are entering a period when political pressure may result in certificate revocation based on the IP address being in a country whose government is doing something CAs do not like, regardless of anything to do with a domain owner.
If I understand the RFC correctly, DANE/TLSA provides a way to cryptographically verify a certificate without any additional organization. Firefox should support this by default.
Comment 92•2 years ago
|
||
Got published as RFC 9102.
Reopening.
Reporter | ||
Comment 93•2 years ago
|
||
We have no plans to implement this feature.
Description
•