Something about DNS(cdybedahl.github.io)
cdybedahl.github.io
Something about DNS
http://cdybedahl.github.io/
35 comments
VeriSign (.COM) already is a CA, and browsers cannot blacklist them. The CA is just too popular for that: any browser that did that would be seen as "the browser that randomly presents scary warnings", no matter how justified.
ICANN isn't, to my knowledge, so I guess the question is whether you consider ICANN more trustworthy than the least trustworthy of the other 170-odd organizations your browser trusts.
DNSSEC certainly has other problems, and yes the trust model is bad, but it is not somehow worse than X.509.
ICANN isn't, to my knowledge, so I guess the question is whether you consider ICANN more trustworthy than the least trustworthy of the other 170-odd organizations your browser trusts.
DNSSEC certainly has other problems, and yes the trust model is bad, but it is not somehow worse than X.509.
Sure it is: X.509 might be de facto controlled by NSA and GCHQ, but DNSSEC is de jure controlled by them.
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.
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.
X.509 is de facto controlled by every major intelligence agency in the world, which is obviously worse than just one.
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.
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.
Why do I care how many intelligence agencies have their hooks into CAs? DNSSEC is permanently compromised by the two I'm most worried about: NSA and, worse, GCHQ, the world's most unhinged SIGINT agency.
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.
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.
OK, then, if you insist on a point-by-point rebuttal:
- 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.
- 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.
Large CAs, including Symantec, are already cooperating with CT. CAs will enroll in CT because if they don't, they won't be able to sell higher-value products (like the EV bar) to their users.
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?
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?
Oh, don't get me wrong: I actually like absolutely nothing about DNSSEC.
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.
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.
Yea, I have been thinking about a DNSSEC2 that would for example uses online signing for a while now, in addition to things like DNSCurve/DNSCrypt.
That first case ("sites I use often") seems like a pretty big win. I want my browser crying holy murder if my bank or webmail cert suddenly changes.
Yes it is, which is why it's a good idea. Such a good idea, in fact, that OpenSSH security in practice relies on it!
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.
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.
One thing I keep on reminding people is that DNS is/was the first scalable, high distributed, key value store.
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.
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.
It's easy to scale a KV store with no online updates.
This is pretty good, but some minor nits -
>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.
>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.
There is a updated version at http://calle.dybedahl.se/dns.html . I don't know if any of your issues are clarified though.
Apparently I shared the wrong version :(
Apparently I shared the wrong version :(
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 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.
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.
Heh, I'm very familiar with DNS and the RFCs. I was questioning the wording of the statement. "A name and all the names below it that are not delegated to someone else is collectively called a zone". The names in the com zone are delegated to someone else, hence the NS records. Just murky wording to me, but maybe I'm reading it wrong.
Not sure if you're the author, but thanks for the DNSSEC section!
The defenses of DNSSEC are a bit confused.
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.
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.
I'm becoming a serial defender of DNSSEC here :)
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.
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.
You're leaving some details out, here:
* 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.
* 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.
(I assume you meant to s/Verizon/Verisign/ there.)
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.
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.
Funny thing that TACK and the Google project for certificate transparency have exactly the same failure point of DNSSEC, in that both will make all the names public.
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.
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.
It's not just the trustworthyness of the browser vendor, but the scope. Any of the 177 delegates are trusted to sign for any domain on the internet. Further, those 177 delegates can mint CA=True certificates for anyone they like and our browsers trust those subordinates by default. That's what the author means by we can't know how many CA's we trust.
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.
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.
Another thing to keep in mind with DNSSEC is that DNS has a 512 byte limit when using UDP. Anything higher than that requires a full TCP connection - pretty costly. Anyone know if progress is being made on using ECC instead of RSA for DNSSEC?
EDNS0 extends this to 4096, and it seems pretty well supported.
You can use ECC in DNSSEC, though not many people do yet.
You can use ECC in DNSSEC, though not many people do yet.
One reason they don't is that major DNSSEC validators have been seen rejecting ECC signatures.
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.
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.
What is your opinion on DNScrypt? As far as I've seen it is somewhat the Yin to DNSSEC's Yang.
This wasn't directed at me and I'm not the crypto expert Mr. Ptacek is, but DNScrypt and DNSSEC really aren't related as they serve different functions. DNScrypt encrypts you the user, and your lookups. DNSSEC is meant to protect site owners by authenticated the answers given to resolvers.
DNSSEC is top-down. DNSCrypt is bottom-up.
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.
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.
Am I the only one whos sad no one is really picking up dnscurve? DJB has some very interesting things to say about crypto in dns, and there nothing to stop you from having dnscurve and dnscrypto working with dnssec for a pretty nice potential future of dns.
Great article. I'm going to start sending this to my DNS-confused friends now!
Hmm, the link is no longer valid. Has the site moved?
Indeed, check here : http://calle.dybedahl.se/dns.html
BTW, since the article doesn't mention it, the C in CNAME stands for canonical.
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/