Now, when you think about that, remember: the DNSSEC trust model starts with an entity that can sign anything under .COM. You can't not have that entity in DNSSEC. Now you understand one reason I think DNSSEC sucks.
*.*Tell me what you'd personally do to deal with a rumored breach or misuse of .COM?
Remember: under DNSSEC, Libya would have been BIT.LY's CA.
True, but at least it says that prominently on the tin.
Please understand this: you can stop trusting every HTTPS/SSL CA today, and, as you visit HTTPS sites, accept their keys individually.
There is absolutely no reason whatsoever for anyone to settle on this point, either with negligent corporations or with governments.
My point is the advantage here is that the name "BIT.LY" itself clearly says who you are trusting to certify that name: You are trusting ".LY". If you do not trust ".LY", you can go about your day ignoring "∗.LY" sites, and your ability to separately trust "∗.NO" is unaffected.
The fact that governments ultimately control most of these trust domains is unfortunate, but it is still nice to be able to have different trust domains. If I want to actually see the unedited propaganda of the Libyan government, then I sure as hell do trust the Libyan government the most to deliver that; conversely, I trust the US Government the most to certify that I'm actually browsing whitehouse.gov.
Such a model allows me to see when I am browsing the Libyan-government-guaranteed part of the Internet - I know that any lies I read are Libyan government lies, and if my pockets are fleeced they will be fleeced with Libyan government complicity or incompetence.
And sure, it'd be great if governments didn't have a monopoly - if there was, say, a Google-guaranteed part of the Internet too. This isn't too crucial, though: ultimately, all corporations are answerable to at least one government, that can compel the corporation to act in the interest of that government. By trusting Verisign I'm already trusting the US Government - it's just hidden.
Allowing seperate, clearly dilineated trust domains that are obvious to the user is a good idea, because it would facilitate competition between the trust anchors of those domains. If a trust domain built a reputation for highly trustable, carefully-validated certificates, it could charge a premium. A ".CH" domain as the online equivalent of a Swiss bank account? (probably not literally .CH of course, given their reputation regarding crypto).
Having those trust domains associated with governments is also reasonable: the citizens that government is answerable to can punish conspiracies and cock-ups, and all corporations are ultimately answerable to a government, so by trusting a corporation you are really trusting a government anyway.
(By the way, I am not a spear-carrier for DNSSEC - I would just like to be able to restrict the domains that a CA is able to vouch for).
If you dislike the CA model that HTTPS/SSL has, you should have your spear pointed at DNSSEC.
Like I said upthread, we probably agree regarding the current HTTPS/SSL PKI.
Remember: With or without DNSSEC Libya sets falsified MX records for bit.ly, buys a certificate (without any hacking), because after all, a valid SSL certificate for domain.example means that someone verified that you indeed receive mail for webmaster@domain.example, and also suddenly has a certificate for Bit.ly. This has been critized by Kaminsky and other researchers for ages now.
I know you love SSL. In fact, I like SSL too. But please stop advertising the CA system along with it, because it is horribly broken.
If the implication of this a claim that DNSSEC is worse than the current TLS/SSL security model with CAs, that claim is obviously false: having one entity that can sign anything under .COM is better than having three hundred of them.
If that claim is not intended, what do you suggest would be a better approach than DNSSEC?
The resolver software that ultimately makes the trust decision --- examining the RRSIG records in the response and deciding what to display or do as a result --- is running on computers under end-user control. If the end-user, or whoever maintains your browser or other software for them, decides that a particular key has probably been compromised and should not be trusted, no RFC can force their software to treat that key as valid simply because it has a valid DS from its parent zone. You can have a DNSSEC blacklist just as we have openssl-blacklist and openssh-blacklist. You can make your resolver do whatever you want.
Now, this is considerably more work than clicking around your browser's Preferences UI to delete DigiNotar's keys, but it's not as if every user has to do it themself.
However, I appreciate the information about what the DNSSEC quasi-standards say you should program your resolver to do.
In one corner, we have PKI protocol whose trust roots are configurable, so much so that every mainstream browser has point-and-click UI to change them. It so happens that this protocol is also the de facto standard with 15+ years of deployment history.
In the other corner, we have a PKI protocol that, instead of providing configurable trust, hardcodes trust into DNS names. Instead making point-and-click configuration changes, to alter the PKI roots in this scheme you'd have to "violate" the standards of one of the core Internet protocols by building and deploying a noncompliant DNS resolver.
Kragen, why on earth do you prefer the second solution to the first?
First, the existing PKI already hardcodes trust into DNS names. If Libya's registry decides vb.ly is immoral and should be redirected to a server serving up a placeholder page, Violet Blue can't make her site continue working. And they can almost certainly even obtain an X.509 certificate proving that they really do own vb.ly, so that you still get the placeholder page instead of a TLS error page even if you visit the site over https.
Second, the existing PKI grants every CA power over the entire namespace, instead of merely over the names it was established to verify. That means I can't get my intranet site to authenticate properly without granting my company the authority to MITM every site in the world.
As a result of this idiocy, recovering from trust root compromises seems to have gone from being a once-in-a-lifetime catastrophe to a yearly, even monthly catastrophe, to the point that intelligent people think it's important to have a point-and-click UI to recover from it.
The current configuration of the SSL PKI grants every CA power over the entire namespace. But that's not intrinsic to the SSL trust model.
We are zero lines of code away from a key-continuity trust model where no CA's are required for vigilant and technically qualified users. Some people call this "TOFU".
We are zero lines of code away from a cert-pinning model that uses installed based of millions of people to detect bogus certs, regardless of whether Verisign has complied with some government order to sign them.
We are tens --- literally tens --- of lines of code away from a model that cordons off parts of the CN space to specific CAs or notary servers. Don't want Thawte to have a say in whether a cert belongs to EFF.ORG? Don't want to have to depend on key continuity or cert pinning to enforce that? This level of sophistication is almost but not quite a UI feature away from completion.
None of these ideas are trivially implemented with DNSSEC. The entire design of DNSSEC militates against some of them.
Meanwhile: DNSSEC does not exist. Applications are not ready for DNSSEC. Many of them will require new revisions to function properly in a post-DNSSEC world. DNSSEC the way people-who-hate-CA's conceive of DNSSEC requires every user to run a full caching resolver on their desktop. How many people in Iran do that today? Having never been deployed "in the large", nobody knows whether DNSSEC even works.
By any reckoning, we are far more lines of code away from a working DNSSEC trust model than we are from any reasonable improvement to the HTTPS/TLS trust model, which is far more adaptable than DNSSEC (the SSL/TLS PKI has no other dependencies other than SSL/TLS trust, unlike DNSSEC, which also has to make the whole Internet work).
So I'm asking you again: why would you rather deploy DNSSEC than fix HTTPS/TLS?
Please don't say "because I don't trust all the CAs in my browser configuration" again.