First, I'd be a little happier if you didn't misquote me for the convenience of your comment. These weren't my subheds. You've rewritten some of them, condensed others, added one, and misread another, which lead you to suggest that I hadn't "allowed for enumeration of zones" when in fact there's a whole subhed dedicated to it. You could just clarify at the top of your comments that your numbered list is your own, not mine. I'd then strike this part of my comment.
Now then:
1. I do not argue that the CA PKI infrastructure is working. In fact, I state explicitly that it is not. The problem is that DANE's replacement for the TLS PKI is controlled by world governments. At a broader level, the problem is that centralized PKIs don't work against nation-state adversaries. The solution for the TLS CA problem is (a) a race to the bottom for CA pricing, led hopefully by EFF, (b) widespread deployment of public key pinning, which serves both to thwart CA attacks and to create a global surveillance system against them, and (c) the eventual deployment of alternate opt-in TLS CA hierarchies, such that users could for instance subscribe to a hypothetical EFF CA hierarchy. DNSSEC accomplishes none of this.
2. Yes, DNSSEC is a government-controlled PKI. Your whole argument here is that if governments abused it, the Internet would "route around it". You can't make that argument without conceding my point.
3. I didn't write "DNSSEC is insecure" (though I think it is). I wrote that it's cryptographically weak, which it is: it's PKCS1v15 RSA-1024. Crawl signatures back to the roots: you'll see RSA-1024 all the way at the top of the hierarchy. TLS has already deployed forward-secure ECC cryptography and will by the middle of this year see widespread deployment of Curve25519 ECDH and Ed25519 deterministic signatures. DNSSEC simply will not: it will be RSA-1024 for the foreseeable future.
4. "DNSSEC is expensive" is not a subhed in my post. "DNSSEC is expensive to adopt" was, and it is: virtually no networking software currently handles soft failures from lookups, which are a universal shared experience among HTTPS users, and will occur just as frequently with DNSSEC (should it ever be deployed). "DNSSEC is expensive to deploy" is another point I made, which is also true: of the top 50 Alexa sites, why not go look how many are DNSSEC-signed?
5. "DNSSEC is hard" isn't something I wrote at all, so I don't know how to respond to it.
6. "DNSSEC makes for DDoS" is something I think is probably true, but also an argument I wasn't willing to go to bat for, because amplification attacks using ANY queries against normal DNS also work. But sure, if you want to add fuel to the fire.
7. "DNSSEC allows for enumeration of zones" is captured under "DNSSEC is unsafe" in my post. If you answer to this is "don't use DNSSEC for important zones", then we agree, modulo that I think you shouldn't use it at all.
> The problem is that DANE's replacement for the TLS PKI is controlled by world governments.
I think that the concept (though not DANE itself) could be made to work, e.g. by using k-of-n systems to verify that a majority of governments agree to a particular fact. If the US, UK, Russia, Iran and Ghana all agree on a set of facts, those facts are likely to be true; if enough nation-states agree on a set of facts, then those facts might as well be true.
This could be used to secure the root for a nation-state's DNS, since that root is, after all, just a fact.
As an example, a majority of member states could certify that the ICANN board has authority for the root; a majority of the ICANN board could certify that 192.0.2.27 is authoritative for .example; in exactly the same way, 192.0.2.27 could then use its authority to delegate responsibility for example.example to 203.0.113.153, and so forth.
A similar scheme could be used for IP address ownership.
Yeah, any nation state is going to be able to lie about the identity of machines it is responsible for—but it's a government; it can do that anyway. Other approaches like TOFUPOP help there, but at the end of the day the guys who can point guns at a certificate holder have the ability to make him do anything anyway.
This needs to be better explained in depth. Do world governments control DNS because of ICANN's GAC? Does the USG control DNS because ICANN is contracted to the NTIA? Are the root key creators USG agents? What is your reasoning behind world governments controlling DNS and/or DNSSEC?
I can't argue against this statement because it's not clear to me what you actually mean.
I thought I was perfectly clear in which points were not yours. My point with including the whole list of standard arguments against DNSSEC, not only yours, was that they are well known to DNS implementors for over ten years.
1. Since you decide that the whole of DNS is "government controlled" (which is a statement of a kind that are useless to discuss furhter), you must also accept that "a race to the bottom in CA pricing" means certficates generated without human intervention. That would mean a very complex and error prone to implement the same security model as DANE gives you, where domain ownership is cryptographically assured.
2. That is only because "government controlled" is a meaningless phrase. ICANN is not more government controlled than any other organization operating in a jurisdiction. They have a mandate from the US Department of Commerce but that does not mean they are "controlled" by them. It could certainly improve, but the proposals for a multi stakeholder model has so far been thinly veiled attemts to politicize ICANN. That does not mean it can not be done. The fact that they root zone has a spotless record of political meddling so far should count for something.
3. This last statement is incorrect. DNSSEC is not RSA-1024 for the forseeable future. Implementating an alternative way to secure DNS with more modern cryptography is many orders of magnitude more difficult than switching algorithms in DNSSEC, which is completely supported.
4. Again a statement so general it holds true for implementing any world wide standard. If you want every software under the sun to handle lookup failures correctly, that is expensive in itself. Is DNSSEC more expensive than any reasonable alternative? No, probably less so. Failure modes are well understood.
Since the rest of the points weren't raised by you directly (but then again, many times by others) I think we can concede them from any further discussion.
The difference between the insecurity of the CA system and the parallel, comparable insecurity of DNSSEC is that the CA system already exists and DNSSEC TLSA does not in any meaningful way. If DNSSEC TLSA solved real security problems, it would be worth the expense, insecurity, and instability of deploying it. It doesn't though, and thus isn't worth it.
ICANN is not the only problem. Even if ICANN is scrupulously honest, the most popular TLDs are controlled by other organizations.
Not only am I right about RSA-1024 in DNSSEC, but I'm obviously and empirically right about it, as a trip to DNSviz will show you. I'm amused by all the arguments that presume that I'm just Googling random stuff and posting them to see what sticks. Unfortunately, no: I'm an implementor and I've been writing about DNSSEC for more than 7 years. I'm also amused by the objection that because there's an algid somewhere in the DNSSEC RRs, RSA isn't a problem. DNSSEC in its current deployment trajectory is PKCS1v15 RSA.
I am also obviously right that a secure DNS system designed in 2015 would not look like DNSSEC. It would instead be based on online-signing, would use deterministic ECC signatures, and would do full end-to-end encryption of DNS requests instead of trying to shoehorn the whole protocol into standard DNS RRs.
You've also missed the point about software reliability. Software today gets away with a shortcut in which it can assume that failed DNS lookups are the result either of user error or lack of connectivity. Software does not generally have a recovery state machine for lookup failures. That cheat stops working when DNSSEC failures are introduced to the model.
> the CA system already exists and DNSSEC TLSA does not in any meaningful way.
Well, DNS exists. Most of what makes you uncomfortable with DNSSEC are really issues with DNS. But as long as DNS names are what you wish to secure, no alternative system could do that in a way you would be comfortable with. Unless you wish to replace the domain name system itself?
I guess what we disagree about here is if we need an alternative to the CA model. I believe we do, and I believe the most sound way is to cryptographically assert domain ownership. Such a model would be transparent in operation, not add any failure points except for the ones we already have in the domain name system, and be very clear to the end user in what it is we really secure.
(A common point made in the SSL CA system is that we want to secure "entities" and not domain names, and that is why a world wide PKI system should never sign keys based on domain names alone. I believe that is completely and utterly wrong. Most users actually do want to know that they are talking to the domain name bigbank.com, not the entity "Big Bang Co. Ltd.".)
Given that premise, DNSSEC at least solves the right problem. One could argue that its cryptographic implementation is not great, and it's not, but it's pretty much identical to TLS and IPsec which is what we will use for the forseeable future.
> Not only am I right about RSA-1024 in DNSSEC, but I'm obviously and empirically right about it, as a trip to DNSviz will show you.
I do not follow at all. We will be "stuck with RSA-1024 for the forseeable future" because that is what people use today. That does not follow at all.
You could just as easily have said "we will be stuck with SHA1 for the forseeable future" one year ago, but reality just 12 months later looks very different.
> It would instead be based on online-signing,
This is a point you can make, but I disagree. We have seen more and more centralization in DNS serving infrastructure. Amazon and Cloudfront and the other big players serve more and more of the domain name space.
I think giving them complete powers to fully sign replies on behalf of the domain owners would be a mistake. It would clearly be a step to a more centralized PKI.
(And if government interference is what you fear, you should absolutely want offline signing. Amazon has yielded to government interference more times than I can count, while ICANN has not. Not that an online signing model would free you from ICANN of course.)
> Software today gets away with a shortcut in which it can assume that failed DNS lookups are the result either of user error or lack of connectivity.
No, you missed the point here, which is that all reasonable alternatives are worse off. Unless your idea is to swap out the domain name system or stay with the broken CA model, of course.
Startcom is great (I use it for a bunch of domains), but there are some caveats:
* They are only free for personal, non-commercial use. You can't (contractually) use them for your startup.
* They are free to acquire, but they charge to revoke them. So don't lose your key (even accidentally, via something like heartbleed).
* Their roots are not in the Windows XP base install. They are included in an optional update, but my experience with a web site that had old machines in its demographics showed that practically no one had it installed. Given that XP is no longer supported by Microsoft, this point is getting less and less relevant as the days go by.
Sorry, but no. Their response to Heartbleed - refusing to revoke certs without charge even in an emergency - means I can never recommend Startcom again.
Failing to revoke keys on any notification they've been compromised is a CA/B forum guideline reason to revoke their trust as a CA, actually. They still have valid unrevoked signs on thousands of Heartbleeded keys now, because they issued them free but won't withdraw them without charge.
This is the second thing I've seen you say that surprised me, given your background (the first being that you actually use DANE). TLS certificate revocation is, of course, theater --- and will be until widespread deployment of some kind of "must-staple" extension --- and Start's refusal to issue revocations had virtually no operational impact on the Internet or on privacy.
Now then:
1. I do not argue that the CA PKI infrastructure is working. In fact, I state explicitly that it is not. The problem is that DANE's replacement for the TLS PKI is controlled by world governments. At a broader level, the problem is that centralized PKIs don't work against nation-state adversaries. The solution for the TLS CA problem is (a) a race to the bottom for CA pricing, led hopefully by EFF, (b) widespread deployment of public key pinning, which serves both to thwart CA attacks and to create a global surveillance system against them, and (c) the eventual deployment of alternate opt-in TLS CA hierarchies, such that users could for instance subscribe to a hypothetical EFF CA hierarchy. DNSSEC accomplishes none of this.
2. Yes, DNSSEC is a government-controlled PKI. Your whole argument here is that if governments abused it, the Internet would "route around it". You can't make that argument without conceding my point.
3. I didn't write "DNSSEC is insecure" (though I think it is). I wrote that it's cryptographically weak, which it is: it's PKCS1v15 RSA-1024. Crawl signatures back to the roots: you'll see RSA-1024 all the way at the top of the hierarchy. TLS has already deployed forward-secure ECC cryptography and will by the middle of this year see widespread deployment of Curve25519 ECDH and Ed25519 deterministic signatures. DNSSEC simply will not: it will be RSA-1024 for the foreseeable future.
4. "DNSSEC is expensive" is not a subhed in my post. "DNSSEC is expensive to adopt" was, and it is: virtually no networking software currently handles soft failures from lookups, which are a universal shared experience among HTTPS users, and will occur just as frequently with DNSSEC (should it ever be deployed). "DNSSEC is expensive to deploy" is another point I made, which is also true: of the top 50 Alexa sites, why not go look how many are DNSSEC-signed?
5. "DNSSEC is hard" isn't something I wrote at all, so I don't know how to respond to it.
6. "DNSSEC makes for DDoS" is something I think is probably true, but also an argument I wasn't willing to go to bat for, because amplification attacks using ANY queries against normal DNS also work. But sure, if you want to add fuel to the fire.
7. "DNSSEC allows for enumeration of zones" is captured under "DNSSEC is unsafe" in my post. If you answer to this is "don't use DNSSEC for important zones", then we agree, modulo that I think you shouldn't use it at all.