Illustrating example: the article asserts that, unlike X.509, DNSSEC has a "single root of trust". DNSSEC advocates like to make this point because it sounds like it makes sense: the DNS tree has a single root, DNSSEC is a PKI built on the DNS tree, ergo: single root of trust.

But that's not really true. In reality, every .COM name has at least the equivalent of two CAs: whoever controls .COM, and whoever controls the DNS root.

What's worse, both .COM and (less importantly) the DNS root are overtly supervised by the US government. In fact, all of the most popular TLDs, most especially .IO, are similarly influenced by US intelligence partners.

Further: if you want to analyze X.509 and DNSSEC in terms of "roots of trust", here's an interesting thing to consider: X.509 has a different kind of "single root of trust": the browser CA store. When a CA misbehaves, browsers will blacklist it. When .COM misbehaves, browsers will not be able to blacklist the TLD operator.

Here's more, of course: http://sockpuppet.org/blog/2015/01/15/against-dnssec/

We're in the midst of what will be a decade-long X.509 cleanup effort, disentangling untrustworthy CAs (all of them) from the outsized role they have in the Internet trust model. CT logs will play a role. Nuking egregiously bad CAs will play a role. The adoption of new cheap/free CAs like LetsEncrypt will play a role. Certificate pinning and HPKP will play a role.

We are not in the midst of any effort at disentangling NSA and GCHQ from the DNS, nor will we ever be: that entanglement is by design in DNSSEC.

And the "X.509 cleanup effort" you refer to (really several entirely separate initiatives) has basically no chance of disentangling CAs from governments. Certificate pinning is the only piece that can gain traction without explicit support of governments (except cheap/free CAs, which solve a different problem). That's great for things you use all the time from a single device, but otherwise useless.

I gave a whole list of ways in which "the security system formerly known as X.509" is being repaired. You rebutted basically no part of that list. For instance: I remain totally unclear on why you think CT logs require government cooperation.

You've also oversimplified pinning. Pinning isn't simply "trust on first use" for TLS. It works in conjunction with the CA system. To break a pin, you have to implicate a CA. That means every time someone tries to deploy a fake CA certificate, they risk bumping into one of the tens of millions of deployed browsers that check pins; if they do, the browser vendors get evidence that the CA is compromised.

- CT logs will play a role.

Requires CA cooperation, and therefore government cooperation because the largest CAs are owned by governments.

- Nuking egregiously bad CAs will play a role.

This can only be done for small (i.e. non government owned) CAs, or you create the perception that your browser does not work.

- The adoption of new cheap/free CAs like LetsEncrypt will play a role.

This solves a real problem, but a different problem than this.

- Certificate pinning and HPKP will play a role.

This only helps in two cases: sites I use often and widespread attacks. Widespread HTTPS MITM is detectable anyway.

The problems with DNSSEC seem so obvious to me, and, obviously, I have problems taking pro-DNSSEC arguments seriously. I'm curious though; you sound plenty smart. What is it about DNSSEC that you actually like?

I just don't think "It has a worse security model than HTTPS" is a true statement. I think smart people need to keep working on the authentication problem, because we clearly have not solved it yet -- including with DNSSEC.

It still won't stop someone who really wants to compromise you, which means that you still will need to trust CAs from time to time.

Not only that it can be partitioned into subdomains. There is also the concept of scope, which means you can adjust default records

So for things like service discovery you do things like this:

metrics-server.datacenter1.example.com A 10.10.20.1 metrics-server.datacenter2.example.com A 10.20.20.1

on each client the search scope will be set by the DHCP server. This means that if you lookup metric-server in datacenter1 you'll get 10.10.20.1, and in datacenter2 you'll get 10.20.20.1

however it can be a pain in the arse.

>A name and all the names below it that are not delegated to someone else is collectively called a zone

I don't understand this statement. For example, the vast majority of the 'com' zone are NS records for subdomains, and that is considered part of the com. zone.

The DNSSEC section is decent. NS rrsets don't get signed, and a distinction in DNSKEY types should probably be pointed out. Also, the talk of 'shadow nodes' is confusing and I still don't know what they are referring to.

The NS records themselves are within 'com' so they are part of the 'com' zone. It is the NS record itself that forms the delegation. The article elsewhere makes a mention of "someone else" but of course you can delegate to yourself. What makes a delegation is an NS record. What makes a zone is really an SOA record (and the corresponding sibling authoritative NS records in that zone).

FWIW, RFC 1034 and 1035 are very readable.

http://tools.ietf.org/html/rfc1034

http://tools.ietf.org/html/rfc1035

Aside, I always found it somewhat interesting that the DNS RFCs go into the implementation details of BIND. It's not really relevant to the operation of a other DNS implementations what the syntax of a zone file should be. Or how replication (AXFR) should be handled. The SOA record itself contains information that only BIND even cares about.

Apparently I shared the wrong version :(

First, the proper comparison for X.509 trusted sources is between the root anchor and the browser vendors not the specific trust sources chosen by Mozilla (or Microsoft or whomever).

Second, we can tell how many entities we have to trust, and the author just counted them: Mozilla's 177 delegates. Arguably, with DNSSEC, we can't tell how many entities to trust: how many zones has `com.` signed?

Third, X.509 allows the signing of arbitrary names largely because DNS isn't trustworthy. (And also because DNS isn't the only naming system people care about.)

Finally, with only one trusted path, there is only one place you need to attack to fool everyone.

You are inverting your second question. Every zone that we trust 'com.' to sign can only be singed by Verizon. There's one single point of trust here, you know what it is, and can choose what point you want when getting a domain.

About that one trusted path, you are also inverting the issue. With X.509 there are 100 places you can attack, any one of them being enough to fool everybody. With DNSSEC you have one single place (more like 3) you can attack, and can only fool people about a limited number of sites.

Really, DNSSEC is objectively better than X509, as for every flaw in DNSSEC, there is one equal or worse equivalent flaw on X509. Except of course for the issue of publishing all the signed names, that is a different trade-off between DoS protection and obscurity, so you can have a subjective opinion about.

* The CA system is not overtly delegated to governments, and the top level domains of the DNS tree are.

* Most of the world's most popular and privacy-sensitive websites are locked into domains controlled by governments with aggressive signals intelligence programs.

* CAs are revokable without global coordination, and DNS zones are not, so if an DNS zone owner begins misbehaving, there will be few options to restore trust.

* Modern X.509 doesn't merely rely on the CA tree, but also on (a) pinning and soon (b) CT logs, both of which create Internet-wide surveillance systems that make it extremely risky to subvert TLS sessions using compromised CAs.

* For that matter, pinned certificate take X.509 almost entirely out of the equation for sensitive sites like Google Mail; attempts to MITM Google are probably what caused the last few CA compromises to be detected.

* The cryptography in DNSSEC dates back to the 1990s; even the variant of RSA that it uses is obsolete.

Are you saying that if I don't trust [current .com delegate] to manage my naming authentication, I can choose .ly or .io instead? I was trying to point out that DNSSEC can't do anything about googIe.com or similar i18n-style attacks.

I'm glad that TACK exists, and I'm glad people like tptacek are advocating for it. But DNSSEC and X.509 aren't the only two possibilities for the future of secure infrastructure.

TACK is great. Google's certificate transparency isn't. And, yes, we need more proposals. The more, the better.

And, by the way, yes, it's Verisign, thanks.

With DNSSEC there is one public key hash stored in the com zone which authenticates the public key for the paypal.com domain.

With many possible trusted paths for validation you only need to attack the weakest one, and because CA's are not restricted in what domains they can sign, you will still fool everyone.

You can use ECC in DNSSEC, though not many people do yet.

Also, however much ECC gets deployed in DNSSEC:

* The roots and TLDs remain RSA-signed (until very recently, they were signed RSA-1024!)

* Those RSA records are obsolete PKCS1v15 RSA

* The ECC used by DNSSEC is NIST p- curve DSA; both that curve and that construction are also obsolete, and error-prone

* There is virtually no chance any of this is going to change, since change would require coordinated updates to thousands of DNSSEC validators, which were --- against the advice of lots of people --- deployed aggressively and in advance of real demand, thus locking DNSSEC down to 1990s crypto despite the fact that it's first commercial use was in 2015.

Thankfully, two of the four most popular browsers on the Internet have declared publicly that they're not going to support DNSSEC (or DANE, the DNSSEC CA replacement scheme). DNSSEC is a dead letter. People who are interested in DNS security should get to work designing SDNS or Secure-DNS or CryptoDNS or whatever the successor to DNSSEC will be called.

DNSSEC provides no value until the whole system works. DNSCrypt adds value even if just two systems use it.

DNSSEC uses 1990s crypto. DNSCrypt uses 2010+ crypto.

DNSSEC doesn't protect name resolution queries. DNSCrypt only protects name resolution queries.