I don't have a strong opinion on DNSSEC myself, but I agree with him that DANE is a bad replacement for standard TLS connections. DNSSEC is by far not the best security protocol ever designed, but it can protect to some threats, like cache poisoning.
Honestly, while I do truly believe that DANE is an insane response to the Snowden disclosures that centralizes Internet trust and hands the keys over to the FVEY IC, that's not my biggest problem with DNSSEC. It's just the argument that I think has the strongest valence on HN.
Most of that post isn't about NSA controlling the Internet. It's about what a mess DNSSEC is, and how little it does to protect anything on the Internet even in a universe where it's actually deployed.
But in today's world where CAs issue certificates based on simple DNS A and MX record lookups for ownership verification, whoever controls the root zone or the relevant TLD zones can get "the keys" they want already.
First, nobody believes any part of the FVEY IC can't already get TLS certificates. DNS spoofing? They've already got CA=YES certificates.
Second, DNSSEC doesn't even prevent this attack! All it does is attempt to protect name lookups. SMTP itself doesn't magically become secure just because there was a signature on an A record.
Finally, we're already doing something that meaningfully blunts this attack. No matter how the CA system is compromised, browsers still monitor certificate pins. When pins break, the CA associated with the malicious certificate gets reported. When that happens, as we've seen repeatedly, the CA gets penalized --- or put out of business entirely.
Public key pinning, CT, and surveillance is actually making a dent in the Internet trust problem. DNSSEC is a charade --- or, I think, something worse than that: you can't simply "revoke" .COM.
2. stop using SMTP for domain verification, and issue the certificate at the same place that a domain's NS records are set (i.e. in a domain registrar's control panel), preferably in way that clients won't accept certificates issued by unrelated (and there unauthorized) domain registrars.
As I mentioned the other day, nobody is talking about revoking ".com". We'd have multiple registrars under ".com", and if one behaves badly, revoke that particular registrar. Also, if ".com" itself is out to spoof you, then you have already lost as a .com domain owner, so maybe we SHOULD revoke all of .com if proof of that surfaces, so that everyone will know that .com can't be trusted at all anymore.
Verifying based on DNS records is only a baseline. CAs can and do require more. If you want higher security for your domain, you can:
1. Make business arrangements with a handful of CAs to require additional verification when issuing certificates for your domain.
2. Use public key pinning to restrict your domain to those CAs.
3. Monitor certificate transparency logs to ensure that your chosen CAs are only issuing authorized certificates, and that other CAs are not issuing certificates for your domain. (CT does not have full coverage yet, but it has already done more to improve PKI security than DNSSEC has.)
If one of your chosen CAs violates your trust, you drop them like a hot potato. DNSSEC removes this agility, leaving you at the mercy of your registrar and every zone operator higher than you in the hierarchy.
You're already at the mercy of every CA whose certificates are trusted by default by browsers. You can request additional verification, but that's not going to stop someone from turning the screws on a CA on the other side of the planet, whose certificates are nonetheless accepted-by-default by users' systems, and as long as they're not totally foolish in deploying that cert (i.e. it's used in targeted attacks only), you'd never see it via certificate transparency.
(And yes, for the record, HPKP blunts the compromised-CA weapon somewhat, but adoption has been pretty crummy. IIRC the latest iOS Safari and IE don't support it at all.)
HPKP works no matter how many people adopt it. The most important sites on the Internet are all generally pinned (very few of them are DNSSEC-signed).
Moreover, the surveillance aspect of HPKP doesn't require IE and Safari adoption. Chrome and Firefox are way more than substantial enough to make the risk of detection not worth the reward of trying to deploy a forged certificate. Note how many times in the past few years Google has slapped down CAs for "accidentally" issuing Google certificates.
The end game for certificate transparency is that browsers will reject a certificate unless the server can prove that it has been submitted to at least two logs. In fact, as of the next version of Chrome, this will be required of all Symantec certificates due to their past misdeeds.
The fact that HPKP and CT have not been fully adopted yet is not a good argument against them when the alternative under discussion is DNSSEC+DANE, which has seen even less adoption and doesn't even solve the problem.
DNSSEC is Unnecessary
All secure crypto on the Internet assumes that the DNS lookup from names to IP addresses are insecure.
Yes, because without DNSSEC they ARE insecure. With DNSSEC, we can store data in DNS that requires security. (eg. certificates for https)
DNSSEC is a Government-Controlled PKI
[...]
Had DNSSEC been deployed 5 years ago, Muammar Gaddafi would have controlled BIT.LY’s TLS keys.
How is that diffirent from current CA system, where any CA can issue certificate for any domain? Not only Muammar Gaddafi controlled bit.ly TLS keys, but anyone who can force/exploit any CA to issue certificate for it.
DNSSEC is Incomplete
[...]
In fact, it does nothing for any of the “last mile” of DNS lookups: the link between software and DNS servers. It’s a server-to-server protocol.
If client software want to be sure that reply received from ISP provided server is legitimate, it must verify DNSSEC trust chain. Though, if single DNS server is fully trusted, there is RFC 7858: "Specification for DNS over Transport Layer Security (TLS)"
DNSSEC is Unsafe
Yes, I agree that these chained NSEC are stupid, but it is not critical problem. CloudFlare solved that by: "We return an answer that says, “sure, the name exists, but the type you asked for does not”. This allows us to return only one NSEC record in negative answers!" (https://blog.cloudflare.com/dnssec-done-right/)
Yours is a rebuttal that literally leads off by suggesting we store certificates for HTTPS in a PKI that is --- not by innuendo, not by implication, not just as a consequence of how the real world works, but de jure, as labeled on the tin --- controlled at the top by world governments, most prominently those of the Five Eyes Intelligence Community.
There's an FAQ, linked at the top of that post, which probably addresses any of the other arguments you'd try to raise here.
The current CA system is already in place; an alternative should be better in the goals we wish to achieve, otherwise why incur in the switching costs?
It does not do that. This is a misconception. It is not a little bit false; it is totally false. We will not stop having 1035 CAs if DANE is deployed. We will have more: one new one for each of the TLDs, plus a new one at the root.
I'm of more or less the opposite opinion: DNSSEC overall is pretty terrible. DANE is possibly a slight improvement over the existing CA system for some threat models, though only very slight. That improvement is frequently zero depending on the chosen threat model, though I've yet to see a real-world scenario where it's worse.
DNSSEC is a complicated proposal with basically no adoption that requires widespread adoption to accomplish anything. We've had much better (though still not perfect) ways to improve authority-resolver security for years (DJB's DNSCurve for example). Given this, its only purpose is to make DANE happen. That benefit is way below the cost (again, maybe actual zero benefit depending on your point of view). It may even have a negative benefit by delaying a switch to an actually-good solution once someone figures one out (which nobody has, quite yet).
This RFC was proposed in 2012. It provides a simple way to place TLS server certs in DNS, in addition to or even in place of usual TLS certificate negotiation. In theory, it lets us even remove the TLS chain of trust in favor of the one provided by DNSSEC.
However, it is obviously dependent on DNSSEC, and as the latter isn't quite ubiquitous yet, DANE cannot be widely deployed.
OpenSSL 1.1.0 gained support for DANE TLSA peer authentication.
Obtaining and performing DNSSEC validation of TLSA records is
the application's responsibility. The application provides
the TLSA records of its choice to OpenSSL, and these are then
used to authenticate the peer.
The TLSA records need not even come from DNS. They can, for
example, be used to implement local end-entity certificate or
trust-anchor "pinning", where the "pin" data takes the form
of TLSA records, which can augment or replace verification
based on the usual WebPKI public certification authorities.
[Viktor Dukhovni]
DANE is a scheme whereby TLS certificates are stored in DNSSEC-signed DNS records.
The conventional nerd wisdom is: this is fantastic, because it's a step towards replacing the totally broken CA system with something that technical people can take direct control over. I like that story too.
Unfortunately, the conventional wisdom is totally wrong. DANE does not eliminate CAs. Even in a world where DANE is universally deployed in all browsers (no browser does it today --- and several tried, and then removed support), we will still have CAs. What DANE will give us is a bunch of new CAs: one for every TLD, and one at the root. Don't take my word for this: Adam Langley, TLS superhero of the Chromium team, wrote an excellent blog post explaining why.
But it gets worse. Those new CAs DANE deployed? They are controlled overwhelmingly by world governments. The most popular DNS TLDs are all legally bound to the governments of the FVEY IC. Here again you don't have to take my word for it: all you have to do is look at what the DOJ did to file sharing sites by asserting its control of the DNS.
Lots of things are happening behind the scenes to make the train wreck of Internet trust a little better:
* CA certificates themselves are hurtling towards "free", especially now that we have Let's Encrypt
* Major browsers are implementing HPKP and static key pinning, so that once you see a certificate for a pinned domain, your browser remembers and screams bloody murder if it changes unexpectedly. Someone who attempts to get a domain-validated certificate to hijack Google Mail will, in the best case, succeed only in getting the CA dumb enough to do that kicked out of the Chrome and Firefox root trust store.
* Google and others are coordinating efforts to monitor certificate issuance, not just using certificate pins but also with initiatives like Certificate Transparency, which involves cooperation from CAs that Google has repeatedly shown willingness to require as a condition of being included in their trust store.
DNSSEC is not one of those things. It's a broken protocol, an attempt to deploy decades-outmoded cryptography across the backbone of the Internet, and, in the very best case, a bit of security theater.
This, to me, is one of the rare cases where I think random end users who aren't in the unofficial cabal of TLS library maintainers, ISP operators, or standards committee members can make a real difference in Internet security.
Don't let people pretend that DNSSEC is a good thing just because the name ends in SEC. When you see people cheerleading DNSSEC deployments, challenge them. DNSSEC deployment is failing, and has been failing for something like 15 years now. Let's try to keep it that way!
Those new CAs DANE deployed? They are controlled overwhelmingly by world governments.
As opposed to all the other CAs, which are also controlled by governments. Every CA has some person or group of people who are able to cause certificates to be issued, and that person or people can be compelled to produce certificates at the whim of their government.
CA certificates themselves are hurtling towards "free", especially now that we have Let's Encrypt
Not that Let's Encrypt's security model is … to trust unsecured DNS. So it's strictly worse than DNSSEC.
* Major browsers are implementing HPKP and static key pinning, so that once you see a certificate for a pinned domain, your browser remembers and screams bloody murder if it changes unexpectedly. Someone who attempts to get a domain-validated certificate to hijack Google Mail will, in the best case, succeed only in getting the CA dumb enough to do that kicked out of the Chrome and Firefox root trust store.
I think pinning is orthogonal to DNSSEC: one might implement both DNSSEC and it.
* Google and others are coordinating efforts to monitor certificate issuance, not just using certificate pins but also with initiatives like Certificate Transparency, which involves cooperation from CAs that Google has repeatedly shown willingness to require as a condition of being included in their trust store.
One might, of course, do the same thing with DNSSEC, and then come to understand which nation-states actually do break DNS and which refrain from doing so, rather than spreading FUD about them.
I'm sorry, I'm a little lost at "the solution to governments having captured individual CAs is to add a set of new CAs that they control directly and that can't be revoked because they're tied to the DNS".
I'm sorry, I'm a little lost at "the solution to governments having captured individual CAs is to add a set of new CAs that they control directly and that can't be revoked because they're tied to the DNS".
That's because it's not a solution. There isn't a non-political solution.
By making it explicit rather than implicit one is forced to confront the truth, and be honest about it. .com is owned by the United States; .ru is owned by Russia; .ly is owned by Libya; .io is owned by the United Kingdom.
If we got rid of non-DNS CAs (for host-verification purposes, anyway), it would, however, mean that only the U.S. may legally suborn .com, .org &c.; that only Russia may suborn *.ru, and so forth. That's a pretty big win over the present situation, in which every government who can lay its hands on a CA employee can get a certificate for any site in the world.
People keep saying this in response to ".COM is owned by the USG no matter what" and it's not true.
The USG's ownership of .COM does not in fact enable them to intercept Google Mail requests. The reason it doesn't is that if you get a CA to issue a bogus Google Mail request for surveillance purposes, Google will put your CA out of business.
Chrome has mid-high double digit market share. No matter what the DNS hierarchy says, and no matter what some random CA says, Chrome ships knowing what a valid certificate for Google Mail looks like. When you try to tell Chrome something is a Google property that isn't, Google finds out, and they take action.
It used to be they only did this for non-Google properties if you asked them nicely. But now there's a protocol that automates it, called HPKP.
HPKP does not give a fuck what government is currently in power in Libya. If a CA starts issuing bogus .LY certs, that CA probably isn't going to be issuing certificates for .LY --- or many anything else --- for much longer.
This helps everybody, not just the people running Chrome. IE doesn't support HPKP. But every single person running Chrome is participating in a certificate surveillance system that will light up if someone makes the mistake of feeding them a bogus cert.
Google is also getting the ball rolling on Certificate Transparency, which directly monitors all certificate issuances from participating CAs. Browser vendors have shown a willingness to force CAs to participate if they make any mistakes at all.
This is a problem that is in the process of being solved. DNSSEC is a MONUMENTAL STEP BACKWARDS. Thankfully, it isn't going to happen, but we can make that not-happening even clearer and faster by noticing when people talk positively about DNSSEC and then challenging them.
Deploying DANA doesn't mean that we can't use HPKP. It is independent solution.
Chrome has mid-high double digit market share. No matter what the DNS hierarchy says, and no matter what some random CA says, Chrome ships knowing what a valid certificate for Google Mail looks like. When you try to tell Chrome something is a Google property that isn't, Google finds out, and they take action.
And this situation won't change with DANA.
HPKP does not give a fuck what government is currently in power in Libya. If a CA starts issuing bogus .LY certs, that CA probably isn't going to be issuing certificates for .LY --- or many anything else --- for much longer.
If they control DNS for domain, they can change MX records for verification and buy certificate in any legitimate CA.
DANE does harm HPKP. Part of the point of HPKP is that when pins are broken, browsers can punish CAs. You can't punish the TLDs that way. HPKP assumes agility. DANE removes agility.
Equally importantly: DANE doesn't actually solve any problem we have today. HPKP does. Why would you spend a penny, let alone tens of millions of dollars, to deploy something that is a step backwards for our security? What's the point?
Regarding MX records: I think you need to re-read the post, its FAQ, or the comments on this thread, because it's been addressed ad nauseam.
With DANE there will be no CAs, so yes, there will be no CAs to punish. But owners of root zone can already change DNS records to buy certificate in any CA, and you cannot punish them for that because they aren't required to do any validation above checking DNS records for non-EV certs.
In worst case DANE is equally secure as current CA system (ok, except that weak RSA, but I hope it will be fixed soon). Why you want to keep CAs, when you have to waste resources on constantly monitoring and punishing them, while with DNSSEC you can ditch them? In both systems DNS root zones owners can buy/generate certificates for child zones. This was also addressed ad nauseam.
The reason it doesn't is that if you get a CA to issue a bogus Google Mail request for surveillance purposes, Google will put your CA out of business.
Will it? If the USG orders Symantec to issue a bogus certificate, will Microsoft, Apple, Google, Mozilla & Opera all refuse to accept Symantec certs? If the PRC orders CNNIC to issue a bogus certificate, will they all refuse to accept CNNIC certs?
I grant you that they could; I just don't think it's very likely. Sure, DigiNotar was put out of our misery, but it was small and marginal.
I agree with you on the crypto of DNSSEC. Where I disagree is that there is any meaningful ownership structure of DNS names other than … the DNS hierarchy. DNS is feudal: the holder of foo.bar holds it at the pleasure of the owner of bar; the holder of quux.foo.bar holds it at the pleasure of both foo.bar & bar. Ignoring those facts is IMHO silly, and forces sloppy thinking.
People want multiple things out of the CA system, which is part of why it's so terrible. One of those is tying hosts to real-life identities. DNSSEC is indeed terrible at that. Another is tying hosts to hostnames; DNSSEC at least attempts to do that (as you note, not terribly well, although maybe it's fixable).
Is it an insane idea to incorporate the blockchain technology into the current PKI system so that every time a CA signs a key it must insert a new transaction into the blockchain which links it to the certificate? We could have a full, transparent and cryptographically secure certificate log.
That's called an hash chain[1], they've been around for a while. In my country, receipts systems are actually required to implement hash chaining to allow the authorities to detect "missing" receipts (for tax-avoidance control purposes).
Whenever DANE comes up, DNSSEC in general comes up.
Whenever DNSSEC comes up, a raft of people arrive to say "but this means the government will have complete control and can do what they want".
The evidence of this actually being a reality is then given as the us government took down a known and acknowledged "piracy" site.
A further example is given that e.g bit.ly would have been effectively controllable by Gadafi.
First off: no one forced them to use the .ly domain. If you choose to use a country code domain you should be aware of the situation the controlling country is in.
Second: if your only argument supporting the idea that democratic governments - even those as fucking ass backwards as the USA - will arbitrarily take control of your domain, is a file sharing site, I suggest you look for more evidence.
rant about DANE from tptacek incoming
http://sockpuppet.org/blog/2015/01/15/against-dnssec/
I don't have a strong opinion on DNSSEC myself, but I agree with him that DANE is a bad replacement for standard TLS connections. DNSSEC is by far not the best security protocol ever designed, but it can protect to some threats, like cache poisoning.
Honestly, while I do truly believe that DANE is an insane response to the Snowden disclosures that centralizes Internet trust and hands the keys over to the FVEY IC, that's not my biggest problem with DNSSEC. It's just the argument that I think has the strongest valence on HN.
Most of that post isn't about NSA controlling the Internet. It's about what a mess DNSSEC is, and how little it does to protect anything on the Internet even in a universe where it's actually deployed.
But in today's world where CAs issue certificates based on simple DNS A and MX record lookups for ownership verification, whoever controls the root zone or the relevant TLD zones can get "the keys" they want already.
First, nobody believes any part of the FVEY IC can't already get TLS certificates. DNS spoofing? They've already got CA=YES certificates.
Second, DNSSEC doesn't even prevent this attack! All it does is attempt to protect name lookups. SMTP itself doesn't magically become secure just because there was a signature on an A record.
Finally, we're already doing something that meaningfully blunts this attack. No matter how the CA system is compromised, browsers still monitor certificate pins. When pins break, the CA associated with the malicious certificate gets reported. When that happens, as we've seen repeatedly, the CA gets penalized --- or put out of business entirely.
Public key pinning, CT, and surveillance is actually making a dent in the Internet trust problem. DNSSEC is a charade --- or, I think, something worse than that: you can't simply "revoke" .COM.
Maybe we could
1. take away all the existing CA=YES certificates
2. stop using SMTP for domain verification, and issue the certificate at the same place that a domain's NS records are set (i.e. in a domain registrar's control panel), preferably in way that clients won't accept certificates issued by unrelated (and there unauthorized) domain registrars.
As I mentioned the other day, nobody is talking about revoking ".com". We'd have multiple registrars under ".com", and if one behaves badly, revoke that particular registrar. Also, if ".com" itself is out to spoof you, then you have already lost as a .com domain owner, so maybe we SHOULD revoke all of .com if proof of that surfaces, so that everyone will know that .com can't be trusted at all anymore.
Maybe we could actually fix the problem instead of just moving it around.
Verifying based on DNS records is only a baseline. CAs can and do require more. If you want higher security for your domain, you can:
1. Make business arrangements with a handful of CAs to require additional verification when issuing certificates for your domain.
2. Use public key pinning to restrict your domain to those CAs.
3. Monitor certificate transparency logs to ensure that your chosen CAs are only issuing authorized certificates, and that other CAs are not issuing certificates for your domain. (CT does not have full coverage yet, but it has already done more to improve PKI security than DNSSEC has.)
If one of your chosen CAs violates your trust, you drop them like a hot potato. DNSSEC removes this agility, leaving you at the mercy of your registrar and every zone operator higher than you in the hierarchy.
You're already at the mercy of every CA whose certificates are trusted by default by browsers. You can request additional verification, but that's not going to stop someone from turning the screws on a CA on the other side of the planet, whose certificates are nonetheless accepted-by-default by users' systems, and as long as they're not totally foolish in deploying that cert (i.e. it's used in targeted attacks only), you'd never see it via certificate transparency.
(And yes, for the record, HPKP blunts the compromised-CA weapon somewhat, but adoption has been pretty crummy. IIRC the latest iOS Safari and IE don't support it at all.)
HPKP works no matter how many people adopt it. The most important sites on the Internet are all generally pinned (very few of them are DNSSEC-signed).
Moreover, the surveillance aspect of HPKP doesn't require IE and Safari adoption. Chrome and Firefox are way more than substantial enough to make the risk of detection not worth the reward of trying to deploy a forged certificate. Note how many times in the past few years Google has slapped down CAs for "accidentally" issuing Google certificates.
The end game for certificate transparency is that browsers will reject a certificate unless the server can prove that it has been submitted to at least two logs. In fact, as of the next version of Chrome, this will be required of all Symantec certificates due to their past misdeeds.
The fact that HPKP and CT have not been fully adopted yet is not a good argument against them when the alternative under discussion is DNSSEC+DANE, which has seen even less adoption and doesn't even solve the problem.
Yes, because without DNSSEC they ARE insecure. With DNSSEC, we can store data in DNS that requires security. (eg. certificates for https)
How is that diffirent from current CA system, where any CA can issue certificate for any domain? Not only Muammar Gaddafi controlled bit.ly TLS keys, but anyone who can force/exploit any CA to issue certificate for it.
If client software want to be sure that reply received from ISP provided server is legitimate, it must verify DNSSEC trust chain. Though, if single DNS server is fully trusted, there is RFC 7858: "Specification for DNS over Transport Layer Security (TLS)"
Yes, I agree that these chained NSEC are stupid, but it is not critical problem. CloudFlare solved that by: "We return an answer that says, “sure, the name exists, but the type you asked for does not”. This allows us to return only one NSEC record in negative answers!" (https://blog.cloudflare.com/dnssec-done-right/)
That's only point with I agree.
Yours is a rebuttal that literally leads off by suggesting we store certificates for HTTPS in a PKI that is --- not by innuendo, not by implication, not just as a consequence of how the real world works, but de jure, as labeled on the tin --- controlled at the top by world governments, most prominently those of the Five Eyes Intelligence Community.
There's an FAQ, linked at the top of that post, which probably addresses any of the other arguments you'd try to raise here.
DNSSEC is a failed project, and a dodged bullet.
How is that diffirent from current CA system
The current CA system is already in place; an alternative should be better in the goals we wish to achieve, otherwise why incur in the switching costs?
It is better in that we're eliminating CAs and limiting possibility of issuing malicious certificates to root domain owner.
It does not do that. This is a misconception. It is not a little bit false; it is totally false. We will not stop having 1035 CAs if DANE is deployed. We will have more: one new one for each of the TLDs, plus a new one at the root.
You can use TLSA PKIX-TA record to limit CA which can issue certificate for given domain.
Also, if DANE is deployed, we can ditch CAs for non-EV certificates.
First, no you can't, not with DANE:
https://www.imperialviolet.org/2015/01/17/notdane.html
Second: you already can limit which CAs can issue a certificate for your domain, without forklifting out the DNS:
https://developer.mozilla.org/en-US/docs/Web/Security/Public...
I'm of more or less the opposite opinion: DNSSEC overall is pretty terrible. DANE is possibly a slight improvement over the existing CA system for some threat models, though only very slight. That improvement is frequently zero depending on the chosen threat model, though I've yet to see a real-world scenario where it's worse.
DNSSEC is a complicated proposal with basically no adoption that requires widespread adoption to accomplish anything. We've had much better (though still not perfect) ways to improve authority-resolver security for years (DJB's DNSCurve for example). Given this, its only purpose is to make DANE happen. That benefit is way below the cost (again, maybe actual zero benefit depending on your point of view). It may even have a negative benefit by delaying a switch to an actually-good solution once someone figures one out (which nobody has, quite yet).
This RFC was proposed in 2012. It provides a simple way to place TLS server certs in DNS, in addition to or even in place of usual TLS certificate negotiation. In theory, it lets us even remove the TLS chain of trust in favor of the one provided by DNSSEC.
However, it is obviously dependent on DNSSEC, and as the latter isn't quite ubiquitous yet, DANE cannot be widely deployed.
OpenSSL 1.1.0 gained support for DANE TLSA peer authentication.
Changelog: https://www.openssl.org/news/cl110.txt
API: https://www.openssl.org/docs/manmaster/ssl/SSL_dane_enable.h...
The RFC for storing/lookup OpenPGP keys in DNS via DANE was published recently:
"DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP"
https://tools.ietf.org/html/rfc7929
All documents from the DANE working group are here:
https://datatracker.ietf.org/wg/dane/documents/
Edit: Since there is lot of negativity towards DNSSEC here, please have a look at the following link, so you get both sides of the arguments
http://blog.easydns.org/2015/08/06/for-dnssec/
For those unaware:
DANE is a scheme whereby TLS certificates are stored in DNSSEC-signed DNS records.
The conventional nerd wisdom is: this is fantastic, because it's a step towards replacing the totally broken CA system with something that technical people can take direct control over. I like that story too.
Unfortunately, the conventional wisdom is totally wrong. DANE does not eliminate CAs. Even in a world where DANE is universally deployed in all browsers (no browser does it today --- and several tried, and then removed support), we will still have CAs. What DANE will give us is a bunch of new CAs: one for every TLD, and one at the root. Don't take my word for this: Adam Langley, TLS superhero of the Chromium team, wrote an excellent blog post explaining why.
But it gets worse. Those new CAs DANE deployed? They are controlled overwhelmingly by world governments. The most popular DNS TLDs are all legally bound to the governments of the FVEY IC. Here again you don't have to take my word for it: all you have to do is look at what the DOJ did to file sharing sites by asserting its control of the DNS.
Lots of things are happening behind the scenes to make the train wreck of Internet trust a little better:
* CA certificates themselves are hurtling towards "free", especially now that we have Let's Encrypt
* Major browsers are implementing HPKP and static key pinning, so that once you see a certificate for a pinned domain, your browser remembers and screams bloody murder if it changes unexpectedly. Someone who attempts to get a domain-validated certificate to hijack Google Mail will, in the best case, succeed only in getting the CA dumb enough to do that kicked out of the Chrome and Firefox root trust store.
* Google and others are coordinating efforts to monitor certificate issuance, not just using certificate pins but also with initiatives like Certificate Transparency, which involves cooperation from CAs that Google has repeatedly shown willingness to require as a condition of being included in their trust store.
DNSSEC is not one of those things. It's a broken protocol, an attempt to deploy decades-outmoded cryptography across the backbone of the Internet, and, in the very best case, a bit of security theater.
This, to me, is one of the rare cases where I think random end users who aren't in the unofficial cabal of TLS library maintainers, ISP operators, or standards committee members can make a real difference in Internet security.
Don't let people pretend that DNSSEC is a good thing just because the name ends in SEC. When you see people cheerleading DNSSEC deployments, challenge them. DNSSEC deployment is failing, and has been failing for something like 15 years now. Let's try to keep it that way!
As opposed to all the other CAs, which are also controlled by governments. Every CA has some person or group of people who are able to cause certificates to be issued, and that person or people can be compelled to produce certificates at the whim of their government.
Not that Let's Encrypt's security model is … to trust unsecured DNS. So it's strictly worse than DNSSEC.
I think pinning is orthogonal to DNSSEC: one might implement both DNSSEC and it.
One might, of course, do the same thing with DNSSEC, and then come to understand which nation-states actually do break DNS and which refrain from doing so, rather than spreading FUD about them.
I'm sorry, I'm a little lost at "the solution to governments having captured individual CAs is to add a set of new CAs that they control directly and that can't be revoked because they're tied to the DNS".
That's because it's not a solution. There isn't a non-political solution.
By making it explicit rather than implicit one is forced to confront the truth, and be honest about it. .com is owned by the United States; .ru is owned by Russia; .ly is owned by Libya; .io is owned by the United Kingdom.
If we got rid of non-DNS CAs (for host-verification purposes, anyway), it would, however, mean that only the U.S. may legally suborn .com, .org &c.; that only Russia may suborn *.ru, and so forth. That's a pretty big win over the present situation, in which every government who can lay its hands on a CA employee can get a certificate for any site in the world.
People keep saying this in response to ".COM is owned by the USG no matter what" and it's not true.
The USG's ownership of .COM does not in fact enable them to intercept Google Mail requests. The reason it doesn't is that if you get a CA to issue a bogus Google Mail request for surveillance purposes, Google will put your CA out of business.
Chrome has mid-high double digit market share. No matter what the DNS hierarchy says, and no matter what some random CA says, Chrome ships knowing what a valid certificate for Google Mail looks like. When you try to tell Chrome something is a Google property that isn't, Google finds out, and they take action.
It used to be they only did this for non-Google properties if you asked them nicely. But now there's a protocol that automates it, called HPKP.
HPKP does not give a fuck what government is currently in power in Libya. If a CA starts issuing bogus .LY certs, that CA probably isn't going to be issuing certificates for .LY --- or many anything else --- for much longer.
This helps everybody, not just the people running Chrome. IE doesn't support HPKP. But every single person running Chrome is participating in a certificate surveillance system that will light up if someone makes the mistake of feeding them a bogus cert.
Google is also getting the ball rolling on Certificate Transparency, which directly monitors all certificate issuances from participating CAs. Browser vendors have shown a willingness to force CAs to participate if they make any mistakes at all.
This is a problem that is in the process of being solved. DNSSEC is a MONUMENTAL STEP BACKWARDS. Thankfully, it isn't going to happen, but we can make that not-happening even clearer and faster by noticing when people talk positively about DNSSEC and then challenging them.
Deploying DANA doesn't mean that we can't use HPKP. It is independent solution.
And this situation won't change with DANA.
If they control DNS for domain, they can change MX records for verification and buy certificate in any legitimate CA.
DANE does harm HPKP. Part of the point of HPKP is that when pins are broken, browsers can punish CAs. You can't punish the TLDs that way. HPKP assumes agility. DANE removes agility.
Equally importantly: DANE doesn't actually solve any problem we have today. HPKP does. Why would you spend a penny, let alone tens of millions of dollars, to deploy something that is a step backwards for our security? What's the point?
Regarding MX records: I think you need to re-read the post, its FAQ, or the comments on this thread, because it's been addressed ad nauseam.
With DANE there will be no CAs, so yes, there will be no CAs to punish. But owners of root zone can already change DNS records to buy certificate in any CA, and you cannot punish them for that because they aren't required to do any validation above checking DNS records for non-EV certs.
In worst case DANE is equally secure as current CA system (ok, except that weak RSA, but I hope it will be fixed soon). Why you want to keep CAs, when you have to waste resources on constantly monitoring and punishing them, while with DNSSEC you can ditch them? In both systems DNS root zones owners can buy/generate certificates for child zones. This was also addressed ad nauseam.
Will it? If the USG orders Symantec to issue a bogus certificate, will Microsoft, Apple, Google, Mozilla & Opera all refuse to accept Symantec certs? If the PRC orders CNNIC to issue a bogus certificate, will they all refuse to accept CNNIC certs?
I grant you that they could; I just don't think it's very likely. Sure, DigiNotar was put out of our misery, but it was small and marginal.
I agree with you on the crypto of DNSSEC. Where I disagree is that there is any meaningful ownership structure of DNS names other than … the DNS hierarchy. DNS is feudal: the holder of foo.bar holds it at the pleasure of the owner of bar; the holder of quux.foo.bar holds it at the pleasure of both foo.bar & bar. Ignoring those facts is IMHO silly, and forces sloppy thinking.
People want multiple things out of the CA system, which is part of why it's so terrible. One of those is tying hosts to real-life identities. DNSSEC is indeed terrible at that. Another is tying hosts to hostnames; DNSSEC at least attempts to do that (as you note, not terribly well, although maybe it's fixable).
Is it an insane idea to incorporate the blockchain technology into the current PKI system so that every time a CA signs a key it must insert a new transaction into the blockchain which links it to the certificate? We could have a full, transparent and cryptographically secure certificate log.
check out certificate transparency https://www.certificate-transparency.org/
That's not quite the same, but I just found this NeoDNS[0] proposal, and it seems to be just what I described.
[0] https://rot256.io/post/neodns/
edited: Apparently it was briefly discussed at HN only 2 days ago: https://news.ycombinator.com/item?id=12370146
It's actually one of the few non-insane ideas about blockchains. But it has already been done as another commenter already posted.
That's called an hash chain[1], they've been around for a while. In my country, receipts systems are actually required to implement hash chaining to allow the authorities to detect "missing" receipts (for tax-avoidance control purposes).
[1] https://en.wikipedia.org/wiki/Hash_chain
Whenever DANE comes up, DNSSEC in general comes up.
Whenever DNSSEC comes up, a raft of people arrive to say "but this means the government will have complete control and can do what they want".
The evidence of this actually being a reality is then given as the us government took down a known and acknowledged "piracy" site.
A further example is given that e.g bit.ly would have been effectively controllable by Gadafi.
First off: no one forced them to use the .ly domain. If you choose to use a country code domain you should be aware of the situation the controlling country is in.
Second: if your only argument supporting the idea that democratic governments - even those as fucking ass backwards as the USA - will arbitrarily take control of your domain, is a file sharing site, I suggest you look for more evidence.