DNS is already a a distributed chain of trust. I trust that the well know ftp site will give me a good hints file to get to the root servers. I trust that the root servers will provide me with the proper ns and glue records for the tld servers. I trust that the tld servers will provide the correct ns and glue records for the domain I want to resolve. DNSSEC just formalizes the trust with digital signatures.
A traditional CA validates empirically that a customer controls a domain at some point in time. DNSSEC is a stronger validation of control of the domain, because it's a property of the domain itself.
Trusting the domain registry to indicate who controls a domain makes a lot more sense to me than trusting a third party. If I can't trust the DS records, I can't trust the NS records either.
A DS record doesn't indicate a connection between an organization and a domain though, which a traditional CA supposedly might.
> A DS record doesn't indicate a connection between an organization and a domain though, which a traditional CA supposedly might.
Only if you get an EV certificate, no? My understanding is that the only checks required for getting a normal certificate issued is to verify that the person holding the key that you're signing is in control of the domain. (Verified through methods such as setting particular DNS records, proving control of the email on the WHOIS data, or setting up an HTTP server at a particular DNS address.)
Then again, most sites just use a basic cert, so perhaps DNSSEC provides most of what is needed.
Some of the certificates I've purchased have involved verifying some details of the organization, even though they weren't EV. I believe we needed a Dun and Bradstreet number when I got a certificate from Thawte in the late 90s (although I might be misremembering, something at that company needed that number...). And a more recent issuance wanted some other proof of existence / location, they had asked for a lease/utility bill, but issued with our location found in a state corporation database, before I could get a copy of something they would accept. I won't disclose the issuer of the recent cert, but I would put them in the top tier of reputation (and prices).
I would hope an EV process would do a better verification, but I've never needed an EV cert, so I don't know.
DNSSEC is sort of like verifying to everyone that you control the DNS, near the time of use, as opposed to just verifying to a CA at time of issuance. Or in other words, if it's OK for a CA to trust DNS, letting everyone else trust it would be good too.
At least the concept is right, 1024-bit rsa keys are kind of scary. And DNSSEC doesn't address confidentiality, but TLS with SNI also leaks hostnames.
DNSSEC does seem pretty unnecessary at this point for security. It hands more power over the internet to fewer hands, whilst not providing any improved security.
DNSSEC only seems unnecessary under the assumption that you're already making full use of existing security measures everywhere else in the stack. If you live in a world where unencrypted HTTP still exists then it's nice to have some defense against ISPs who like to lie in DNS responses. And even if I am connecting over HTTPS through a shady ISP, I'd prefer not to send any packets at all to the wrong IP rather than wait until it presents the wrong certificate.
> If you live in a world where unencrypted HTTP still exists then it's nice to have some defense against ISPs who like to lie in DNS responses.
As tptacek and others have pointed out numerous times elsewhere on HN (and in the article linked above):
1. DNSSEC doesn't protect against ISPs hijacking DNS responses
2. TLS is easier to deploy than DNSSEC
3. TLS provides more security for the end user than DNSSEC does
3a. If TLS us used, DNSSEC provides essentially no additional security benefits to the end user.
So really, it makes sense to be advocating the use of TLS, which is what projects like Let's Encrypt are all about. DNSSEC is at best a waste of resources that could be better spent on actually securing the Internet through TLS, and at worst actively harmful (because the strongest criticism of TLS is that it centralizes trust in CAs, and DNSSEC centralizes trust even further - in a single entity!)
> I'd prefer not to send any packets at all to the wrong IP rather than wait until it presents the wrong certificate.
I'm not sure what difference it makes to be sending packets to the wrong IP. The whole point of TLS is that it doesn't really matter, because they can't read what you're sending anyway.
Also, the way the Internet works, you're always sending packets through the "wrong" IP addresses, so you should make the assumption that your raw traffic is visible to to any eavesdropper (and therefore encrypt your traffic so that this is not an issue).
> 1. DNSSEC doesn't protect against ISPs hijacking DNS responses
DNSSEC protects signed zones by allowing clients to notice a suspicious lack of a valid signature on responses that should have been signed. DNSSEC doesn't protect unsigned zones, but that shouldn't surprise anyone and isn't really an indictment of DNSSEC's capabilities.
> I'm not sure what difference it makes to be sending packets to the wrong IP.
That malicious IP gets to record what kind of connection my computer was trying to make to that domain, even if the connection attempt is aborted relatively early. That's more information being leaked than if my computer had been able to determine that it got a probably-spoofed DNS response and aborted there.
Playing shenanigans with the DNS server is a lot easier than full-scale snooping and tampering on all traffic, which is why ISPs commonly do the former but the latter is usually only done with NSA involvement.
It needs to be hard for ISPs to direct all mistyped domain names to their own advertising (and in the process, implicitly pretending that the Web is the only use for the Internet) or to claim that sites they don't like don't exist. DNSSEC helps with that.
Some clients don't validate. Some do. Everything on my home network is protected because my router's instance of dnsmasq validates. When I'm away from home, there's dnssec-trigger and a Firefox extension.
I really don't understand why the existence of software that doesn't try to take advantage of DNSSEC is being used as evidence that DNSSEC is incapable of doing something.
A traditional CA validates empirically that a customer controls a domain at some point in time. DNSSEC is a stronger validation of control of the domain, because it's a property of the domain itself.
Trusting the domain registry to indicate who controls a domain makes a lot more sense to me than trusting a third party. If I can't trust the DS records, I can't trust the NS records either.
A DS record doesn't indicate a connection between an organization and a domain though, which a traditional CA supposedly might.