| |||||||||||||
|
| |||||||||||||
What to doWhat to doPosted Feb 2, 2010 17:03 UTC (Tue) by corbet (editor, #1)In reply to: China Internet Network Information Center accepted as a Mozilla root CA by zorro Parent article: China Internet Network Information Center accepted as a Mozilla root CA Individual CAs can be removed via the "advanced" preferences panel. It's instructive, actually, to look at the list - there's a lot of entries there. One could switch to another browser, but it's worth thinking about how open that browser's CA inclusion process is first.
(Log in to post comments)
What to do Posted Feb 2, 2010 17:46 UTC (Tue) by Thue (subscriber, #14277) [Link]
That is a good argument for storing the certificates inside the DNSSEC entry. Then you are not vulnerable to every single signing entity, but only to the very short DNSSEC chain up to the DNS root.
As a side effect, getting a signed certificate for your domain would come free with the domain.
Obviously, Verisign would lose a lot of money in their certificate signing business if that were to happens. It also happens, as I understand it, that Verisign is responsible for part of the process to implement DNSSEC at the DNS root level. In an incredible coincidence, signing the DNS root seems to be taking a very long time...
DNSSEC Posted Feb 2, 2010 18:38 UTC (Tue) by tialaramex (subscriber, #21167) [Link]
A lot of new client software would have to be deployed before this fairytale (which I fully endorse) were to come true. However Verisign don't control the client, and so I believe it's actually possible this could happen.
Their influence (or anybody else's) over what actually happens to the root is dubious. The root operators take its reliability very seriously - it has inadvertently become one of the most vital utilities in the entire world, and so they've been going very slowly, but they are moving. Check out root server L, which is current emitting bogus DNSSEC results. They intend for this behaviour to gradually spread to the other letters (many of which consist of several physically distributed servers) to prove that the infrastructure can cope with the significantly increased load from DNSSEC. Then one day (this summer according to current schedules) the results won't be bogus any more. Tada!
Conspiracy theorists will, of course, continue to believe that the root is controlled by secret Reptilian overlords who seek to suppress the truth about the assassination of JFK or whatever. But for the majority of reasonable people the root will be secure and the question will be - which TLDs and domains do you trust? The ccTLD registries in particular will definitely vary in how trustworthy they are from a general competence standpoint and as a matter of independence from the sovereign governments via which their rights are delegated.
DNSSEC Posted Feb 2, 2010 19:03 UTC (Tue) by Thue (subscriber, #14277) [Link]
On the other hand, to me DNSSEC at the root seems to be a simple problem of load-balancing an embarrassingly parallel problem. Which really should not be that big of a problem to implement; just throw more servers at it behind the load balancers.
I have approximately zero insider knowledge as to what exactly is holding up the deployment of DNSSEC in the DNS root. But I have seen zero good explanations as to why it would not have been implemented long ago if it had any sort of priority. And DNSSEC should have very high priority, if nothing else then because of DNS poisoning.
DNSSEC Posted Feb 2, 2010 19:41 UTC (Tue) by tialaramex (subscriber, #21167) [Link]
Well, how long ago exactly is "long ago" ?
One hold up was that DNSSEC as originally conceived didn't offer privacy, because at that time DNS privacy was regarded as an esoteric thing to desire. If you're willing to admit that gazimble.example.com resolves to 10.1.2.3, why would you care that it's possible for someone to find that out without the advance knowledge of the existence of the name 'gazimble.example.com' ?
But by the time it was first considered good enough to be worth actually implementing things had changed - privacy was the default in many "public" registries as well as most private organisations. DNSSEC was unacceptable in its current form to those entities because it would mean giving up something they were used to having, and in some cases which they had guaranteed to others.
So, back to the drawing board to come up with a way for a DNSSEC server to assert that the name you've asked for isn't known, without having to
pre-cache a denial for every conceivable unknown name
Of course you could argue that this shouldn't have held things up for the root - nobody expects TLDs to have privacy, this was only ever a concern for subdomains. But it was felt that if nobody else was going to deploy there was certainly no reason to _begin_ with the root where problems would be most costly.
DNSSEC Posted Feb 2, 2010 20:12 UTC (Tue) by Thue (subscriber, #14277) [Link]
RFC 5155 defining NSEC3 was published in March 2008. If DNSSEC was high priority, and NSEC3 was not that big of a change over base DNSSEC, then I don't see why it should take more than 6 months to implement at the root level. As I argued previously, once a basic software implementation is in place then it is just a question of load balancing. Other organizations have deployed DNSSEC, so software support exists.
Yes, it is important to take the time to get it right at the root DNS. But this is snails pace. I can't reasonably see that the supposed problems fit the time it is taking, if enough resources were allocated to this important project.
It is possible that we are just dealing with a large slow bureaucracy. But I still don't have to like it :). And it should be blindingly obvious that having Verisign near the center of the effort to implement DNSSEC is a potential conflict of interest. For example, Wikipedia says that Verisign ran the NSEC3 DNSSEC Pilot (http://en.wikipedia.org/wiki/NSEC3#Response_and_NSEC3).
What to do Posted Feb 3, 2010 3:57 UTC (Wed) by pabs (subscriber, #43278) [Link]
I heard a rumour that the monkeysphere folks were extending their SSH/GPG web-of-trust work to HTTPS, which could be another alternative.
What to do Posted Feb 2, 2010 18:08 UTC (Tue) by lkundrak (subscriber, #43452) [Link]
Unless I'm mistaken, switching to another browser would not always be a proper solution. At least fedora packages the Mozilla certificate bundle in a separate package (ca-certificates) and it's depended on nss, openssl, java and probably other ssl implementations. Therefore I presume it would be easiest to rebuild that package to be on "safe" side.
What to do Posted Feb 9, 2010 3:49 UTC (Tue) by sitaram (subscriber, #5959) [Link]
however, when I try to delete them, they always come back when the browser restarts...
I guess I have to dig deeper; regardless of whether this particular one is trustworthy or not, there's got to be a way for one to pare down the list on one's own machine!
|
|
||||||||||||