DANE does not put you as the DNS operator in control of what TLS cert you want to publish (TACK would do that, without requiring any change to the DNS hierarchy whatsoever.) Rather, DNSSEC adds you to a larger set of people who would have the ability to govern what TLS cert applies to your domain; everyone on the DNS hierarchy back up to the root would effectively have the same ability. In a DNSSEC/DANE world, if you have a .LY name, the government of Libya would have a say in what your TLS certs were. How could that possibly be a win?
Please explain to me how this would be possible?
- I sign my .LY domain with DNSSEC and create the appropriate DNSKEY and RRSIG records.
- I create a DS record with a fingerprint of my DNSKEY and via my registrar (typically) upload this DS record to the TLD registry (.LY in this case).
- Additionally, I create a TLSA record in my zone that holds my TLS cert and sign that with my key (creating the associated RRSIG record).
When someone is querying DNS using a DNSSEC-validating DNS resolver, the resolver:
----
1. Gets my DNS records (A, AAAA, MX, TLSA, whatever) from the authoritative name server for my domain (let's assume I operate it), along with the associated RRSIG and DNSKEY records.
2. Gets my DS record from the .LY registry, along with the RRSIG and the DNSKEY for the .LY registry.
3. Gets the DS record for .LY from the root zone, along with the RRSIG and the DNSKEY for the root zone.
4. Presumably has the root's trust anchor already stored.
5. Validates that my DNSKEY has the same fingerprint as that in the DS record received from the .LY registry - and walks back up the chain of trust to ensure that all DS records and DNSKEYs match.
----
Where in there can the government of Libya have a say in what TLS certs I offer?
The best I could see is that the operator of the .LY registry could choose to modify or remove my DS record, which would then mean that my domain would fail DNSSEC validation. But the TLSA record is still coming from my site. All the .LY registry can do is potentially remove the link to the chain of trust.
I really would like to know if I am missing something here.
Is THAT the attack you see?
With DANE you trade a model where 300 CAs around the world each acting alone have the ability to falsify your certificate, to one where you and your top domain do. That's a big win in every which way you look at it.
(It is also worth nothing that control over the domain name implies the power to generate valid certificates not only in DANE but also in today's CA model and most of the competing systems.)
TACK and other systems may or may not help. We don't know until it has been throughly peer reviewed. Most models like it turned out to be vulnerable to a Sybil attack, or be based on plain TOFU.
DNS-based MITM attacks between clients and validators is a red herring. The standard has assumed local validation for many years now.
For my part, I like the mechanism provided by DANE/DNSSEC because it puts me, as the DNS operator, in control of what TLS cert I want to publish. I can publish my own self-signed cert. I can publish a CA-signed cert (or a fingerprint). I can say that I only support TLS certs from a specific CA. I can designate my own trust anchor for the TLS certs coming from my site. I can publish those certs (or fingerprints) in TLSA records and have them then validated up the global chain of trust. I like how the system is put together.
I also like that there are other systems out there like okTurtles and Convergence looking at other alternative mechanisms for securing naming. It's good to have many different systems that in the end can lead to a more secure Internet.