The DNS-Based Authentication of Named Entities (DANE) TLS Protocol
tools.ietf.org
tools.ietf.org
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]
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://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.
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.
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.
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.
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.
(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.)
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 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.
DNSSEC is a Government-Controlled PKI
[...]
Had DNSSEC been deployed 5 years ago, Muammar Gaddafi would have controlled BIT.LY’s TLS keys.
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.
DNSSEC is Unsafe
DNSSEC is Cryptographically Weak
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.
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?
Also, if DANE is deployed, we can ditch CAs for non-EV certificates.
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...
Yes, there is HPKP, but it is "Trust on First Use" and adds entropy for browser fingerprinting.
Meanwhile: it's "trust on first use" for individual connections, but if you break a pin, your browser vendor will find out. It doesn't matter if a pin is broken for a minor reason or because some CA in Uzbekistan falsified the entire chain: either way, shenanigans get CAs penalized. It's happened repeatedly and will happen more and more.
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).
However, it is obviously dependent on DNSSEC, and as the latter isn't quite ubiquitous yet, DANE cannot be widely deployed.
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.
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.
> 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.
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.
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.
> 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.
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.
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).
[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