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.
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.