I'm a bit confused by the text you quote. DNSSEC does protect against MITM attacks. That is specifically what it is designed to do. Unless I am missing something (which could be), the article you reference as "[2]" does not seem to support the idea that DNSSEC doesn't protect against MITM attacks. The mentions specifically how DNSSEC and DANE can protect against those attacks, although the article then discusses the author's issues with trusting the parties involved in the chain of trust.
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.
DNSSEC merely attempts to protect against one MITM attack out of many many possible MITM attacks. In particular: DNSSEC doesn't even protect against DNS-based MITM attacks between browsers and DNS servers.
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?
> 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.
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.
The A or AAAA record is also going to come from wherever the DNS hierarchy says it should come from. If one of the organisations upstream from you in the DNS hierarchy decides they want to police what TLS certificates sites can use by hijacking the sites' DNS and pointing it to their own servers, they can do that just as easily regardless of whether those certificates come from DNS or the traditional CAs. Once they've hijacked the domain, any major CA will happily automatically issue them a valid certificate for it.
So to your point you would see the attack being that the .LY registry would change the NS records for my (fictitious) .LY domain to point to a different set of name servers? i.e. removing my servers as the authoritative ones? And then being able to serve out whatever records they want to? (including a TLSA)
If you have a Libyan domain name, the entity responsible for Libyan domain names can also transfer or shut down your domain. What does that have to do with DNSSEC? Nothing.
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.