Closed Bug 672600 Opened 13 years ago Closed 1 years ago

Use DNSSEC/DANE chain stapled into TLS handshake in certificate chain validation

Categories

(Core :: Security: PSM, enhancement, P5)

Product:
Core
Component:
Security: PSM
Type:
enhancement

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: keeler, Unassigned)

References

(
URL
)

Details

(Whiteboard: [dnssec][psm-would-take])

Attachments

(4 obsolete files)

Attached patch patch to nsNSSBadCertHandler (obsolete) (deleted) — — Splinter Review
If the handshake included a dnssec chain, verify it in nsNSSBadCertHandler and possibly trust the certificate if the chain checks out.
Assignee: nobody → nobody
Component: Libraries → Security: PSM
Product: NSS → Core
QA Contact: libraries → psm
Summary: use dnssec chain verification in nsNSSBadCertHandler (DNSSEC TLS) → Use DNSSEC/DANE chain stapled into TLS handshake in certificate chain validation
Version: trunk → Trunk
Assignee: nobody → dkeeler
Attachment #546861 - Attachment is patch: true
Attachment #546861 - Attachment mime type: text/x-patch → text/plain
We should enable multiple modes of DANE verification. One mode is "certificate chain must be valid and DANE information isn't available or DANE verification must pass." Another mode is "certificate chain must contain one self-signed certificate and DANE verification must pass." The application should be able to enable/disable these modes independently from each other and the default should be to enable only the first mode I mentioned. In order to enable the first mode I mentioned, you will have to put this logic in the cert auth callback instead of the bad cert handler.
(In reply to comment #1) > One mode is "certificate chain must be valid and DANE information isn't > available or DANE verification must pass." This should be "certificate chain must be valid and (DANE verification must pass OR the domain was not marked as "requires DANE"). This depends on a new mechanism for remembering that a domain requires DANE, which should be a new bug.
Attached patch patch for self-signed cert case (obsolete) (deleted) — — Splinter Review
Handles self-signed cert with dnssec chain case (pref'd on 'security.DNSSECTLS.selfSignedCert.enabled')
Attachment #546861 - Attachment is obsolete: true
Attached patch patch (obsolete) (deleted) — — Splinter Review
latest version
Attachment #547138 - Attachment is obsolete: true
Attachment #555231 - Flags: review?(bsmith)
Attached patch patch (obsolete) (deleted) — — Splinter Review
Attachment #555231 - Attachment is obsolete: true
Attachment #557975 - Flags: review?(bsmith)
Attachment #555231 - Flags: review?(bsmith)
Comment on attachment 557975 [details] [diff] [review] patch Clearing review request until we re-assess how this fits in with our certificate validation improvement plans.
Attachment #557975 - Flags: review?(bsmith)
As the RFC DANE was approved on the 14th June 2012 can the inclusion of Domain Authenticated Named Entities TLSA be integrated in the next release of Firefox. Given that it that the new TLSA gives the potential eliminate all CA root certificates within the Firefox this should make certificate management easier. In fact surely the current CA companies should be placing their Root CA certificates into DNS and signing them with DNSSEC.
annie, I don't think the CAs will ever disappear completely. They do fulfill a function, let me explain. There are currently 2 things wrong with the CA-model. 1. There are to many of them, for the CA-model to really work. The EFF SSL observatory found over 2000 CAs and Sub CAs in use on the open Internet, if I remember correctly. The browser trusts a certificate signed by any of them. 2. The pricing model is a race to the bottom (StartSSL has them available for free and a lot of times their checks are faster than the competition because they automated large parts of it). A certificate is a generic product and there is no way for CAs to differentiate as normal users won't look at what CA the cert is signed by. With the current CA-model, there are basically 2 types of verifications for certificates: 1. domain validated - you own the domain, they check the WHOIS information and sent you a verification code by email for example 2. Extended validation ('green bar') - you are a certain organisation and you own the domain ("PayPal, Inc. (US)" owns paypal.com) There used to be just 1 type, but because CAs had to deliver cheaper and cheaper certificates they did less and less checks so now we have 2 types. Getting a certificate for a domain is pretty easy. If you are the owner of pypal.com it is pretty easy to get a cert for it. EV-certificates gives the user an indication that if you want to do business with PayPal the CA checked that the domain owner is who she says she is. For example they check if the organisation is registered in the country of residence. So pypal.com should never get a cert for pypal.com saying the organisation behind that name is PayPal in the US. The number of CAs which create EV-certificates is a lot smaller. DNSSEC with DANE, allows for 4 things, I'll discuss the important ones for this discussion: 1. CA Constraints, a value is stored in DNS and signed with DNSSEC which says only trust this CA for this domain 2. Trust anchor assertion, a value is stored in DNS and signed with DNSSEC which says we used our own CA for this domain 3. Domain-issued certificate, a value is stored in DNS and signed with DNSSEC which says this is the certificate used for this domain So what does DANE solve ?: It fixes the problem of 'to many CAs', because the browser can check if the DNSSEC-verified certificate information in DNS matches the certificate and CA information presented by the server. The domain owner, or actually DNS-operater, thus can be sure that browsers that support DANE will not accept any certificate issues by CAs expect those CAs or even certificates specified. So what does DANE NOT solve ?: Extended validation - the organisation validation So with DANE the user can't be sure he/she actually typed the right name in the address bar and/or clicked a link actually pointing to the real site. That is one reason why the CAs will remain or at least those that do the "real work" (extended validation). Also not all browsers support DANE currently and it will take years before you can use just a DNSSEC/DANE certificate. For compatibility with older or other browsers and other clients you'll need a certificate signed by a CA. DNSSEC is also not available everywhere, there are for example DSL-routers which block DNSSEC-queries because they only understand regular DNS (most of the time: any larger DNS answer). Not all Top Level Domains support DNSSEC currently, al though in one year time 90+ are now signed. Deploying DNSSEC is also not as easy as regular DNS. DNSSEC keys need to be regularly "rolled" and communicated with the Top Level Domain a lot of that communication can't be automated yet in a lot of cases. Because the domain has been registered by a registrar which doesn't support it yet. Summary: DNSSEC/DANE solves some problems, after many years most domains don't need to use a CA for their certificate needs.
Maybe I should add to the summary: A much smaller number of CAs will remain in the browser after all those years, many (sub)CAs currently exists to handle domain validation.
Annie, Leen, and others: Please discuss the pros/cons of DANE vs what we have now in the dev.security.policy mailing list/newsgroup, not in this bug report.
Bill, agree that we don't want the bug to become a debating forum, but would just ask that you guys indicate the resolution back into the bug sometime Real Soon Now.
As RFC6698 (DANE) has been implemented in BIND since 9.9.1-P3 since September 2012 has supported the new TLSA record (DNS Record type 52) to hold Public Key or Server Certificate. Is there any time-line for the RFC6698 support to be included in Mozilla?
FYI, we recently updated our DNSSEC patch for firefox (see https://bugzilla.mozilla.org/show_bug.cgi?id=748232) to also support DANE. It would be great if this functionality could be integrated into Firefox at some point. (The updated patches are at https://www.dnssec-tools.org/svn/dnssec-tools/trunk/dnssec-extras/nspr/sources/ and https://www.dnssec-tools.org/svn/dnssec-tools/trunk/dnssec-extras/nss/sources/)
I would say that this is something we're still interested in, but it has been put on hold due to other higher-priority projects. For more information, you can take a look at https://wiki.mozilla.org/Security/Roadmap (when the DNSSEC-TLS item goes from "Unprioritized" to P1 or P2, it probably means we're actively working on it).
DANE is so cool
(In reply to David Keeler (:keeler) [Winter Jaycation until Jan. 2 or 6] from comment #14) > I would say that this is something we're still interested in, but it has > been put on hold due to other higher-priority projects. For more > information, you can take a look at > https://wiki.mozilla.org/Security/Roadmap (when the DNSSEC-TLS item goes > from "Unprioritized" to P1 or P2, it probably means we're actively working > on it). In light of the NSA/GCHQ MITM attacks, support for DNSSEC/DANE should have the highest priority. CAs apparently are not the beacons of trust we assumed them to be.
DNSSEC/DANE in FF would be awesome.
ping...
I am not actively working on this.
Assignee: dkeeler → nobody
Until this is built into firefox, see https://www.dnssec-validator.cz/, a DNSSEC/DANE/TLSA plugin for firefox and other browsers.
The information in https://wiki.mozilla.org/Security/DNSSEC-TLS-details is quite outdated. It still links to an old IETF draft instead of http://tools.ietf.org/pdf/rfc6698.pdf and the section "6 CNAME issues" is dealt with in the RFC. In case multiple hostnames/domains share the same TLS-certificate (e.g. multi-domain-/wildcard-certificate for shared hosting) you can even use CNAMES with wildcards to have only one TLSA resource-record to change on certificate updates. Example: *._tcp 3600 IN TLSA 1 0 1 c6b6e2ab05d606db8f8b6039c1053bf0430e5d9d75797e5f475f957dd6ff610e *._udp 3600 IN CNAME *._tcp *._udp.www 3600 IN CNAME *._tcp *._tcp.www 3600 IN CNAME *._tcp * 3600 IN CNAME @ @ 3600 IN A 123.123.123.123 @ 3600 IN AAAA 2001:1c50:11:0::1 will assign the certificate-hash in the TLSA-RR to ALL UDP-/TCP-ports on <domain> and *.<domain>. I suggest "tlsa" from the hash-slinger tools (https://people.redhat.com/pwouters/hash-slinger/) which are available in most linux distros to create TLSA records manually: tlsa --create --port '*' --protocol tcp --certificate <cert.crt> --output rfc --usage 1 --selector 0 --mtype 1 <hostname> If your nameservers do not support TLSA-RRs, yet, you can use "--output generic" to generate generic TLSA-RRs. As a quick start you can use https://www.huque.com/bin/gen_tlsa to generate TLSA resource-records. The sections "Transmitting the DNSSEC Chain" and "Format of TLS Extension" are superfluos. If you do a DNS-query for a hostname just check for DNSSEC- and TLSA-resource records. If there are DNSSEC- and TLSA-RRs just do DNSSEC-validation and check if the hash of the certificate or the certificate in the TLSA-RR matches the certificate provided by the server. If TLSA-RR and certificate do not match don't load the page and show an error message. I'm running my three private DNSSECed domains without problems. A good DNS-service should provide automatic creation of DNSSEC-records. The CZNIC-validator (https://www.dnssec-validator.cz/) works fine. As Dnsmasq supports working DNSSEC-validation since version 2.71 most consumer routers will be DNSSEC-capable in near future. Dnsmasq also supports adding custom trust-anchors for any domains/subdomains. That way trust-anchors can be added for each top-level domain if someone doesn't trust IANA/ICANN. DANE can also protect downloads of Firefox/updates/addons against MITM-attacks of intelligence angencies and other criminals.
So almost year has passed since DANE went into roadmap, sadly we still dont see status P1 or P2 on it, are we going to see native DANE support in mozilla in 2015 ? The usage of dnssec generaly is getting to point browsers are actualy the part stopping DANE to be used in production rather then isps not validating dns/tlds not signed. So stop being part of the problem and start beind part of the solution ;) http://www.internetsociety.org/deploy360/dnssec/maps/
Maybe Mozilla inofficially decided they don't want to support DNSSEC? Just wondering because of the recent announcement of their "new baby", together with EFF etc.: https://letsencrypt.org/
Stefan Neufeind, sadly looks like DNSSEC/DANE has too powerful antilobby, even in Mozilla.
Yep, it moves power out of the hands of Mozilla and CAs into the hands of the domain owners... Plus, it makes MITM attacks much more difficult.
(In reply to Stefan Neufeind from comment #23) > Maybe Mozilla inofficially decided they don't want to support DNSSEC? Just > wondering because of the recent announcement of their "new baby", together > with EFF etc.: https://letsencrypt.org/ Who will run the letsencrypt-CA?
Isn't the problem with DNSSEC that some ISP resolving DNS-servers and DSL-routers are not DNSSEC compatible ? (forget validating, but just allowing the new DNSSEC-types to be queried without causing errors)
If an ISP is that incompetent the user should run off like hell ... ;)
Shouldn't validation occur in the browser anyhow?
(In reply to dirk husemann from comment #29) > Shouldn't validation occur in the browser anyhow? Yes. But some resolvers seem to have problems with passing down RRSIG-/DNSKEY-RRs to downstream resolvers which should be fixed by an ISP. By the way, DNSSEC-proxying is snake-oil as an MITM-attacker can suppress the DO-/AD-bit and insert any unsigned resource record. Always validate in the application or at least with the resolver on the host.
> > Shouldn't validation occur in the browser anyhow? > > Yes. But some resolvers seem to have problems with passing down > RRSIG-/DNSKEY-RRs to downstream resolvers which should be fixed by an ISP. > Exactly, also number of broadband-routers is in use as a DNS-relay and they also have problems. In Germany they did a good test in 2010: http://ripe60.ripe.net/presentations/Dietrich-DNSSEC_Support_by_Home_Routers_in_Germany.pdf - not only problems with RRSIG/DNSKEY-RRs, but handling large DNS-responses or support for DNS-over-TCP. http://netalyzr.icsi.berkeley.edu/ has stats from 2011: http://www.npl.co.uk/upload/pdf/satin2011-pres-weaver.pdf Haven't found more recent statistics. A lot of newer broadband-routers don't have this problem anymore. To work around that problem DNSSEC-trigger uses a HTTP(S) fallback: https://www.nlnetlabs.nl/projects/dnssec-trigger/ AFAIK so far no organisation has been willing to host such a fallback for a large userbase. And anycast services don't have the best reputation either.
I don't understand why issues with DNSSEC+DANE should prevent implementation. For the next years CA's will not vanish magically. So if there are problems, the CA fallback is there. So when DNSSEC does not work fallback to CA only and present the user a "Your secure DNS implementation does not work. Contact your network administrator to prevent security trouble." from time to time and you'll see that a year from now on most of these issues will be solved like they few IPV6 issues have been solved. And inbetween implementing DANE for own domains will have a real advantage instead of being only a early adopters playtoy. If at least one of the major browsers would support DANE I'd enable it for all domains I control as soon as possible. But as said above, the new CA initiative is a sign, that DNS based validation is not really wanted.
I don't see why the new CA initiative is a sign against DANE, adding another CA doesn't solve the "too many CAs" problem, unless you actually believe that all other CAs will go out of business and browsers will drop them as trusted roots in the near future. If nothing else, DANE allows a extra layer of verification that has value to the user in establishing trust in the connection. When present, DANE records should be validated and an indication presented to the user.
> I don't see why the new CA initiative is a sign against DANE Not in itself, but together with the fact that for years no progress has been made here regarding DNSSEC and DANE.
Sure, but IMO there are two main reasons why adoption of DNSSEC/DANE has been slow: 1) lack of support for DNSSEC at registrars and DNS providers, 2) lack of support in clients. So there's been a bit of a chicken and egg problem, DNS hosts don't care about supporting DNSSEC because no clients bother to verify DNSSEC, and clients don't bother to verify DNSSEC because so few hosts provide the information. That in itself does not imply that DNSSEC is a bad idea and should not be supported. In fact there has been a significant improvement in support for DNSSEC in the registrar and DNS provider space. All new TLDs are required to support DNSSEC and older TLDs are adding it rapidly. There has also been a recent uptick in support by DNS hosts. Other clients and servers, such as SMTP and XMPP have also been adding support for DNSSEC/DANE, and there has also been growing support for additional DNS record types, such as SSH and PGP keys. The more clients add support for DNSSEC/DANE validation the more demand there will be for support by DNS providers. This has to start somewhere, why shouldn't Mozilla be the pioneer and set a good example?
Hi folks - it's great to see interest and a lively discussion on this topic, but bugzilla isn't the most appropriate place for it. Please do continue this discussion on a mailing list like dev.tech.crypto ( https://lists.mozilla.org/listinfo/dev-tech-crypto ) or dev.security ( https://lists.mozilla.org/listinfo/dev-security ). Thanks!
@David: Could you maybe give a *short* feedback why (as it seems to be) Mozilla seems to be actively ignoring this inquiry? I doubt it can be argued with a lack of interest or "provide patches".
Personally, I think it's a cool idea. However, this feature is not a priority right now because there are a number of unanswered questions as to how to implement and support it and because we are focusing on other technologies that we think will have a greater impact on the security of a larger number of users than this will. I know that's disappointing to hear. However, in the future we might work on making it easier for addons to experiment with different methods of certificate verification, and this could be implemented as an addon that we might eventually incorporate into Firefox.
I guess stuff like this should be in the core. How do i know, which addon can be trusted with validating certificates? I am not even sure, if the AMO review would really catch malicious addons, but addons promising validation and implementing it badly possibly will go unnoticed, while the users think they are safe. For CAs: Same argument as above. In the long run it does not need more CAs, but less. With DANE i need to trust my DNS registar and nobody else. With the current CA situation i need to trust, that my visitors are only trusting trustworthy CAs. Which is not the case in most browsers. So even a CA fallback when a site uses DANE should be disabled eventually.
You cannot trust any code until you have reviewed it yourself. ;-) DNSSEC/DANE is a temporary step to improve domain security. Currently I'm promoting BTLS (Blockchain-based Transport-Layer Security) which uses a blockchain to assign fingerprints of X.509 client-certificates to usernames. It seems to be the only way for tamper-free TLS with domains, too. But it won't allow to dispute domain registrations as there won't be any registries anymore.
Re Comment 40, I have no comment about BTLS, but DNSSEC would be very useful so that the DNS itself could be used to convey application characteristics prior to connection establishment without worrying about downgrade attacks. It is an enabling technology.
It really comes down to a matter of who do I trust? The current situation: I have to trust - my domain name registry - a HUGE number of CAs scattered all over the world (any one of which could be hacked, be used to issue rogue certificates) - my server Essentially 2+X, with X being fairly large. With DNSSEC I can narrow this down to - my current domain name registry - my server Essentially just, ehm, 2. So: required trust with current setup >> required trust with DNSSEC. If Mozilla is really concerned with creating a safe browsing experience it MUST go and support DNSSEC and co. If...
Nobody mentioned yet that DANE solves certificate revocation in a very nice manner. If I get hacked I simply revoke the cert and switch it with a new one in DNS. No need for CRL or OCSP. This should get at least experimental opt-in support on dev so people could start banging on it.
(In reply to imbacen from comment #43) > Nobody mentioned yet that DANE solves certificate revocation in a very nice > manner. If I get hacked I simply revoke the cert and switch it with a new > one in DNS. No need for CRL or OCSP. > You're right. You can just revoke a certificate by removing/replacing it's TLSA-RR from the zone of a domain. DNSSEC also allows to use self-signed certificates. There's no need for CAs when browsers or other TLS-clients support DNSSEC.
Added my vote to this. We should definitely implement this!
Well, they are improving things around revocation and OCSP in Firefox 37 so that is at least something: You can set up your server(s) to do OCSP stapeling and add a HPKP header. Mozilla will add a CRL-like list for the intermediate CA certs. The CA can add an OCSP must-staple to the certificate they issue to you. Result: You control which public keys are valid (make sure you have multiple keys pre-generated) and the CA controls the revocation (and you can contact the CA to revoke a cert). Here are the links: https://wiki.mozilla.org/CA:RevocationPlan https://blog.mozilla.org/security/2015/03/03/revoking-intermediate-certificates-introducing-onecrl/ https://developer.mozilla.org/en-US/docs/Web/Security/Public_Key_Pinning https://blog.mozilla.org/security/2013/07/29/ocsp-stapling-in-firefox/
yes, i'm sure that will be quite nice. the key issue still is: you still are dependent on the CA. OCSP (along with OCSP-stapling) does not address the core of this issue: (a) we need to empower the site owner to control the chain of trust - if they do want to trust a CA, fine let them do that; if they do want to issue their own certs instead, fine let them use DNSSEC/DANE. (b) the CA model is flawed and compromised - c.f. NSA/GCHQ/MITM-certs, etc.
Well, that is why I mentioned the HPKP-header. As long as you use the Public Key Pinning there isn't anyone that can impersonate your site if they don't have a private keys which match the same hash (we assume they will need to have your private key for that). Which CA signed the certificate used is then irrelevant. Obviously: HPKP only helps regular visitors of your site and not first time visitors. With the OCSP improvements you can revoke if one of your private keys or CA keys gets compromised. So it's not yet a 100% perfect*, but a big improvement over everything else we've had so far. Yes, for a short period the person with the compromised key can impersonate your site. At first they can use your old certificate, because they already have your key, getting the certificate is easy. Then you would ask the CA to revoke the certicificate. Now they will need to find an other CA to issue a certificate for your key because OCSP-stapling wouldn't work anymore. As long as the website visitor doesn't see the fake site and visits your real site they can not be fooled anymore as you've obviously updated the HPKP-header. Some people at Google and others are working on http://www.certificate-transparency.org/ to solve the CA part. So you can detect if an other CA issue a cert. And browser would need to reject certificates which didn't include a CT-timestamp. Yep, it's a lot more complicated than I would like to see. * it still needs the OCSP-must staple part. The HTTP-header or X.509 certificate extension hasn't been enabled in Firefox or is on the roadmap to do so in the near future. The header support has been implemented, but not enabled: https://bugzilla.mozilla.org/show_bug.cgi?id=901698 My guess would be they are waiting for the X.509 certificate extenstion to be ready and the change to NSS has been made.
In my opinion it makes no sense to mess about with symptoms of a completely broken system like the CA infrastructure. It's just a waste of man hours. To put it straight: The CA infrastructure is expensive, complicated, error-prone and any CA which has made it into OSes or browsers can fake certificates of anyone for anyone. A lot of CAs think it's legit to issue fake intermediate certificates for "security"-systems like firewalls - which can also be modified for eavesdropping or manipulation of data. So there's no trust either. If you look at the percentage of websites using HTTPS you can clearly see that CA infrastructures are just a big bureaucratic flop preventing the comprehensive roll out of encryption. HPKP is limited to HTTP while DNSSEC/DANE is a generic, protocol-independent solution for any domain-related authentication. Why use an additional authentication tree if we can just put a few additional DNS-records in the already existing DNS-tree? It is also much simpler to understand when name and signature of the name use the same tree/database. OCSP and CRLs have never worked reliably. A lot of CAs don't even support CRLs via IPv6. In my opinion OCSP, CRL-support and HPKP are just bloatwares making applications like Firefox huge, error-prone, not maintainable and eat up man hours. Technically we can solve any problem. Mentally we cannot get our dumb brain to get rid of old habits. So we're stuck in superstition of systems failing over and over. :-(
Politically you're right and i am totally on your side. But technically almost no domain really uses DNSSEC. Maybe an "better validated" badge in firefox could motivate some people, but i doubt it.
It's the typical hen-egg-problem. DNS operators whine about missing client support and client application vendors whine about missing server support resulting in a feature dead-lock. One party just has to start. Mozilla has a powerful position influencing users. I suggest two traffic lights in the address bar: 1. DNSSEC GREEN: DNSSEC correctly validated YELLOW: No DNSSEC records, be careful warning! RED: DNSSEC validation failed, block loading resource 2. DANE GREEN: DANE correctly validated YELLOW: No TLSA records, be careful warning! RED: TLSA record validation failed, block loading resource This will also improve security of Mozilla updates as the download of an update cannot be manipulated by MITM-attacks anymore.
Technically no sane person would run a script from mozilla to alter his configs to set up some bogus certificate. So, now we can agree that this is the same FUD/bull....t as saying "no domain really uses DNSSEC" Could you please provide some real arguments against DNSSEC and not opinions, thx.
DNSSEC seems to have surpassed the hen-egg-stage. Worldwide the validation rate is at just under 13%, with some countries like the USA seeing higher rates of 23% (source: http://stats.labs.apnic.net/dnssec/XA). In fact, there's a very strong growth visible. All TLDs currently have DNSSEC keys, and some of those zones have extremely high signing rates (.nl, the fifth largest ccTLD, is at about 40%). I'd say that we have definitely reached a point where implementing DNSSEC in Firefox makes a lot of sense, and as soon as that's done TLSA will be easy.
It's not really hen-egg problem anymore. Most TLDs are signed, more and more registrars support at least DNSSEC and a lot of DNS resolvers already support DNSSEC including Google DNS. So if you wanted to use DNSSEC/DANE on your server at this very moment you could. The problem is that not a single browser supports it so browsers are the real blockers here. It seems that web services unrelated to browsing will adopt the standard first. Sources: http://www.internetsociety.org/deploy360/dnssec/statistics/ http://www.internetsociety.org/deploy360/blog/2013/10/slides-dnsec-and-dane-deployment-trends-tools-and-challenges/ https://www.icann.org/resources/pages/deployment-2012-02-25-en
That dnssec is not used widely is simply because no program cares, especially the browser. As soon as firefox/chrome or maybe IE starts to change the default behavior to show a yellow instead of a green symbol for sites that have TLS but no DANE , sites will adopt change. There is simply pressure from a large userbase. At least all larger sites will implement it because they don't want to appear unsecure for a default user. This is not a henn/egg problem, its a problem of user visibility and thats a browser responsibility. I blame Google, Mozilla and Microsoft for endangering common users. I really hope its not because of the CA signup fees but of believe in broken technologies like argued before. And don't come up with arguments that some TLDs are not signed. They had the time and now they will get the pressure from their customers, so be it. It's not something invented yesterday.
I did not say it's an argument AGAINST DNSSEC. I said this is the problem. And DNSSEC can be deployed without any browser support at almost no additional cost, but even some registrars do not offer it, yet. So i want DANE to happen, but i do not have very much hope for now.
Current Dnsmasq (>=2.71) already supports DNSSEC-validation and is available in Ubuntu 14.10. It won't take long to make it in consumer routers and other distros. My private .de-domains are already secured with DNSSEC/DANE. So it's possible to use it. The two weak points are finding a registrar which has the capability to handle DNSSEC with TLSA-RRs and application support -> Firefox, etc. Who is in charge of implementing security features like DNSSEC at Mozilla?
Now that even Mozilla plans to mark http deprecated ( https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http) and considers this in the FAQ, is there hope to get this bug fixed? I wanted to suggest to close it with "wontfix" for a while already
Almost two years has passed since DANE went to roadmap, has mozilla security group come to conclusion how to proceed with DANE support on firefox ?
This is not a priority at the moment. See comment 38.
Attachment #557975 - Attachment is obsolete: true
Maybe the recents rfc7671 (and rfc7673) may give some answer to the "number of unanswered questions" discussed in comment 38.
This is a potential implementation of bug 1201841. However, that bug has no current active work being done on it, so it's not even clear if this is the direction the implementation will take. Marking this as WONTFIX until we know if this is the approach we want to take.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
Reopening since we have a MOSS project working on this now. https://blog.mozilla.org/blog/2016/06/22/mozilla-awards-385000-to-open-source-projects-as-part-of-moss-mission-partners-program/
Assignee: nobody → rlb
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Priority: -- → P1
Whiteboard: [psm-assigned]
No longer depends on: 677981
Blocks: 1351684
The MOSS project from Comment 65 is working on this, so setting the priority given that we'd take a patch but it's not being actively worked upon by Mozilla.
Assignee: rlb → nobody
Status: REOPENED → RESOLVED
Closed: 8 years ago → 7 years ago
Priority: P1 → P5
Resolution: --- → FIXED
Whiteboard: [psm-assigned] → [psm-would-take]
Oops, intended to remain open.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Does the MOSS project include integrating getdns into Firefox? Where would I track the progress of that? Does it mean I can fire up Firefox some time in 2018 and see a green padlock on my DANE secured blog? A lot of questions, some answers would be nice too. Letsencrypt is fine but maybe the corporate sponsors decide to flip off the switch one day so DANE is still a sane alternative to all this.
(In reply to @imbacen from comment #69) I think the state of this bug is that if someone has a real plan to use DNSSEC as an enabling capability, then it should get articulated and funded. Until then, let's be careful not to rehash the 67 other comments.
Within Europe the General Data Protection Regulations (GDPR) come into force on May 18th 2018, the key requirement of which is that it is "Security by Design". While much of the focus has been on securing data within systems, they have missed the obvious point of how do you communicate with Web Hosted systems. Communication can be secured using TLS, however without DNSSEC and DANE in place, are organisations doing enough so they are protecting their customers? Organisations will be liable for the corporate 4% or 10% of global revenue in the event of personal data loss, in addition GDPR also introduces the concept of personal liability so individual decision makers can be pursued by data subjects. So the decision not to implement DNSSEC/DANE could prove very expensive and as its easy to implement decision makers will play safe. So this DNSSEC/DANE stapling will become a requirement within the EU for organisations to show that they are complying with the GDPR to protect themselves. Organisations will have to ensure their browser is compliant or they risk having claims against them for not protecting their staff if they lose their data if phished or spoofed when connecting to a website. Similarly home users will become more aware and will wish to protect themselves so that their data loss can not be considered self inflicted. At least with earlier releases of Firefox it was possible to use the DNSSEC/DANE validation plugin from http://www.dnssec-validator.cz/pages/download.html unfortunately the more recent Firefox version rendered this plugin useless. The way DNSSEC and DANE information was presented was very clear and definitely worth adopting. Any outstanding issues with DNSSEC/DANE need to be resolved.
Since Thunderbird apparently is dependent on this core funtionality it is impacted as well and thus falling behind competing applications that offer DANE/TLSA support. Considering that this is open since 7 years and comment #67 (it's not being actively worked upon by Mozilla) it is rather underwhelming that Mozilla is forsaking support for DANE/TLSA. Given the 25K awarded (which date was that?) to getdns it is not transparent how they are developing DANE/TLSA capability for FF/TB other than for their own stubby resolver. In such light it is not helpful to just point to MOSS and that 25K been spent on something that does not provide a patch for FF/TB. What was the purpose of the 25K award then?
I hope it is time for some answers. We want to be in control of security of our own websites. I don't want to know what is your problem with that. I want to know what can be done. Seriously. Should we establish some kind of movement? Will you implement this, if we donate? If we develop this ourselves, will you let us to use it?
At IETF 103 the draft for dnssec-chain-extension was put to rest as WG item. So motivation across the board to use it is very low. I would say: Won't Fix here, unless it gets approved on different routes. Right now it seems wasted time and effort to implement this as it has not much backing.
That's really unfortunate to read, because Mozilla has recently now found a way to deploy DNS to a large number of users which does not depend on users having to wait on their provider or other network operator or equipment supplier to upgrade to something which is DNSSEC capable and not broken in some way. Which makes DNSSEC a lot more viable to be used in Firefox. How is that ? Well Mozilla has added DNS over HTTPS (DoH) protocol to Firefox. So now you can point the browser to a system that can handle such things. Wouldn't it be great if you could also check if what you get from that 'trusted party' is actually correct ? So you don't have to trust them completely.
(In reply to Selek Respa from comment #75) > At IETF 103 the draft for dnssec-chain-extension was put to rest as WG item. > So motivation across the board to use it is very low. Reading the thread it appears that the motivation been always low and killing said extension is a rather lame and retrospective excuse. > I would say: Won't Fix here, unless it gets approved on different routes. Sounds like killing DNSSEC for good then, for the end user that is. What other route could there be? The Thundebird team has made it clear that they will not develop anything DNSSEC/TLSA/DMARC related on their own but only follow suit of what is implemented in core and thus the mail client is deprived of those as well. > Right now it seems wasted time and effort to implement this as it has not much backing. Sound like a forgone conclusion though without justification except perhaps that end user are not aware of DNSSEC/TLSA/DMARC and/or do not care. (In reply to Leen Besselink from comment #76) > That's really unfortunate to read, because Mozilla has recently now found a way to deploy DNS to a large number of users which does not depend on users having to wait on their provider or other network operator or equipment supplier to upgrade to something which is DNSSEC capable and not broken in some way. Which makes DNSSEC a lot more viable to be used in Firefox. From my experience it appears that only a very low percentage of end users, i.e. browser and mail client users, are even aware of DNSSEC/TLSA/DMARC and/or care about it. From that perspective it makes sense that Mozilla is focussing rather on other stuff and yet still wondering, since it was never answered, about the 25K award to getdns to develop a resolver with DNSSEC capabilities but denying the browser and mail client to take advantage of DNSSEC at the same time... It the end user supposed to look into resolver logs when DNNSEC fails?
I'm glad this unneeded complexity is dead. Up to today Nginx doesn't even have reliable OCSP support. If someone could look at how ESNI and HPKP are implemented and provide an experimental patch, we can ask Mozilla to reopen bug 1450674. Then we would have DANE via DNS-over-HTTPS. Integrating TRust-DNS (bug 1500289) should be a long-term task.
(In reply to Jan Andre Ikenmeyer [:darkspirit] from comment #78) > I'm glad this unneeded complexity is dead. Why? This could mean end of CT, CRL, OCSP and all the other CA craziness and put site owner in control. IMHO this should have happened long time ago. > If someone could look at how ESNI and HPKP are implemented and provide an > experimental patch, HPKP was kind of crazy idea right from the start and AFAIK it is already deprecated. ESNI is on its way. > we can ask Mozilla to reopen bug 1450674. Then we would have DANE via > DNS-over-HTTPS. This would be another way to go, but Mozilla has some kind of religious problem with DNSSEC. One way or another, we will not give up.

Cloudflare is working on supporting DNSSEC by default:
https://blog.cloudflare.com/one-click-dnssec-with-cloudflare-registrar/

Hi. Is there any news on DANE/TLSA support on Firefox?

This work is not currently prioritized.

Whiteboard: [psm-would-take] → [dnssec][psm-would-take]

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).

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.

(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.

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.

(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.

@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.

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.

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.

Status: REOPENED → RESOLVED
Closed: 7 years ago → 5 years ago
Resolution: --- → INCOMPLETE

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.

Got published as RFC 9102.
Reopening.

URL: https://www.rfc-editor.org/rfc/rfc910...
Status: RESOLVED → REOPENED
Resolution: INCOMPLETE → ---

We have no plans to implement this feature.

Status: REOPENED → RESOLVED
Closed: 5 years ago → 1 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: