1. Actually, revocation checking does not solve the problem, alteast if someone had the CA private key, they could generate the same ID's as other existing certificate. OSCP/revocation lists only checks id's not names, which makes it not useful for all possible problems.
Neither CRLs nor OCSP are intended to mitigate a CA private key breach.
The only control in the system is to revoke the CA root and that can be effected on Windows by issuing a new CTL (as happened to revoke the Diginotar root) that drops the compromised root. The other browsers have similar mechanisms.
2. I also think DNSSEC can be useful, it would be really helpful for the domain-owner to be able to make it clear that his website uses cert X and cert Y (which implies CA A and CA B). And not any other cert or CA. Deployment of DNSSEC is very slow though at the moment.
The war could well be over by the time DNSSEC is deployed. The Iranian group have developed new attacks and dramatically escalated the sophistication of their attacks. The time between attacks has been weeks, not years. There is simply no prospect of large scale DNSSEC deployment in the next 6 months. the Iranian 'elections' are in March. I can't even see any possibility of deployment ahead of the next presidential election.
We need at least 2 things: - a fallback method that browser makers want to adopt where DNSSEC hasn't been deployed by the ISP or when you are stuck in a "hotel network" or your OS does not support and so on. Because the browser needs to get the keying material to be able to check the if the data is properly signed. It do not think it even matters where it got it from, any old fallback channel might probably do. For OSCP http is used, so maybe that is good enough here too ?
Working on both of those.
- much better industry support for automating the keyrollover communication with TLDs. If I get my domain at some provider and run my own DNS-server there is hardly any provider, if any, which support EPP or whatever to communicate my DS-record to the TLD. Many TLDs that have deployed some DNSSEC don't (yet) even support DNSSEC in their EPP from their direct customers/members.
3. Can you be a bit more specific about what you proposed in 1993 ?
Not without sounding really whinny.
At this point its water under the bridge, I have changed my mind on what the approach to security should be and so has the industry.
The browser that an Iranian dissident should be using is probably not the same as the one your granny uses to shop online for sex toys. There are security concerns in both cases but the risks and issues are totally incommensurate.
No seriously, the "trust" in "trusted third party" has nothing to do with the trust that you put in the second party (i.e. the server or business with which you are communicating). It has all about to do with the trust you put in the third party (the certification agency), that it correctly does its job (only giving certificates to properly identified entities and appropriately securing their infrastructure so that hackers and spies can't just "help themselves"). The threat that SSL certificates are supposed to protect against is wiretapping, not rogue businesses. I'm sure, all of those shady banks that failed in the 2008/2009 crisis had valid SSL certificates, and rightly so!
Let me explain. I have been working on Web security now for 19 years. I was present at the original meetings at which the SSL system was proposed, I convened several of the relevant meetings.
At no time was government wiretap a design consideration for SSL. NEVER. In fact to claim this was totally ridiculous since at the time we were fighting a running battle with the FBI and the NSA who were trying to stop us using strong cryptography at all. The original SSL design was limited to 40 bits and was very clearly crackable.
SSL is not designed to be wiretap proof, my proposal and the EIT proposal were stronger in that regard. But at the time the criteria was whether shopping online could be made as safe as shopping in a store. That was the design criteria by which SSL was judged and the design criteria it passed (after they eventually hired some competent crypto people). I was the person who stated the design criteria at the meeting.
The problem is what they do when they can't reach that data. All the browsers out there now simply fail silently and go to the site anyway.
For some reason this is seen as a problem with CAs and not the broken browsers. But from the browser providers perspective 99% of their customers are really interested in getting to sites reliably and without fuss and less than 1% are dissidents whose lives might be threatened.
This is not the fault of the guy who writes the code. They only own one small piece of the browser and do not get to make the 'commercial' decisions.
Expecting this to be any different with a DNSSEC scheme is to engage in mystical thinking of a naive variety.
The back end security model of the DNS system is not at all good. While in theory a domain can be 'locked' there is no document that explains how locking is achieved at the various registry back ends. A domain that is not locked or one that is fraudulently unlocked is easily compromised.
The part of the CA system that has been the target of recent attacks is the reseller networks and smaller CAs. These are exactly the same sort of company that runs a registrar. In fact many registrars are turning to CAs to run their DNSSEC infrastructure since the smaller ones do not have the technical ability to do it in house. In fact a typical registrar is a pure marketing organization with all technical functions outsourced.
There are today about 20 active CAs and another 100 or so affiliates with separate brands. In contrast there are over a thousand ICANN registrars.
Sure there are some advantages to incorporating DNSSEC into the security model. But to improve security it should be an additional check, not a replacement. Today DNSSEC is an untried infrastructure, it is grafted on to a legacy infrastructure that is very old and complex and security is an afterthought.
The current breach is not even an SSL validation failure. The attacker obtained the certificate by bypassing the SSL validation system entirely and applying for an S/MIME certificate that did not have an EKU (which it should). That makes it a technical exploit rather than a validation issue. DNSSEC is a new code base and a very complicated one. Anyone who tells you that it is not going to have similar technical issues is a snake oilsman.
The big win for DNSSEC is to distribute security policy in a scalable fashion. See my CAA and ESRV Internet drafts.
Imagine that you are visiting slashdot, wouldn't it be better to use SSL than en-clair if the site supports it? Wouldn't it be better to have encryption with a duff cert than no encryption at all? [*]
DNSSEC allows a site to put a flag in its DNS to say 'always use SSL when visiting slashdot on http'. Now the server knows that if it is going to slashdot and it is not encrypted there is a man in the middle. Same for Twitter, Google etd.
DNSSEC can also be used to ensure that the only certs trusted for a domain are ones authorized by the domain holder. This provides an independent trust path to CA issued X.509. If used in combination, security can be improved.
[*] The catch is that showing the user the padlock icon for a duff cert is going to make them less secure. That is why I would like to see the browsers remove the padlock icon completely for DV certs. the only reason the padlock is required is to allow the user to check that SSL is in use. Since the user can't and won't do that reliably it is a poor control anyway. But it is in any case a control that should be enforced by the browser not the user and DNSSEC security policy allows that to happen.
On key distribution, well sure, for typical Web services and for promiscuous security, DNSSEC validated keys are just fine. It is not going to be a money saver. It does not justify a padlock icon (neither does a DV cert). But it is perfectly adequate for most applications.
Unfortunately it is likely that making use of DNSSEC for key distribution is going to be delayed for at least a year due to IETF politics. I blame the people behind the DANE proposal. They have been less than forthcoming about their real agenda from the start and have shown absolutely no willingness to accept any input from other parts of the IETF. The IETF is a consensus based organization but the test is IETF consensus, not working group consensus. If a clique wants to change the rules for handling PKIX certs they have to get an IETF consensus that this should be done.
DANE could have easily been designed in a way that allowed security policy and key distribution to be completely separate. Unfortunately the ruling clique insists these be joined. The result is a spec that is in my opinion undeployable because the transition strategy for a scheme providing positive trust (key distribution) is by necessity very different to that required for a scheme that provides negative trust (key revocation, security policy, etc.).
The threat model in this case is a well funded state actor that might well be facing a full on revolution within the next 12 months. It does not matter how convergence might perform, there is not going to be time to deploy it before we need to reinforce the CA system. [Yes I work for a CA]
I think it most likely we will be seeing the Arab Spring spreading to Syria with the fall of Gaddafi. We are certainly going to be seeing a major ratcheting up of repressive measures in Syria and Iran. Iran knows that if Syria falls their regime will be the next to come under pressure. In many ways the Iranian regime is less stable than some that have already fallen. There are multiple power centers in the system. One of the ways the system can collapse is the Polish model, the people of Poland didn't have a revolution, they just voted the Communist party out of existence. If the Iranian regime ever allows a fair vote the same wil happen there.
Anyone think that we will have DNSSEC deployed on a widespread scale in the next 12 months? I don't and I am one of the biggest supporters of DNSSEC in the industry. DNSSEC is going to be the biggest new commercial opportunity for CAs since EV. Running DNSSEC is not trivial, running it badly has bad consequences, the cost of outsourced management of DNSSEC is going to be much less than a DNS training course ($1000/day plus travel) but rather more than a DV SSL certificate ($6 for the cheapest).
The other issue I see with Convergence is that it falls into the category of 'security schemes that works if we can trust everyone in a peer to peer network'.
Wikipedia manages a fair degree of accuracy, but does anyone think that they really get up to 99% accurate? Until this year the CA system had had three major breaches, all of which were trapped and closed really quickly plus about the same number of probes by security researchers kicking the tires. Until the Diginotar incident anyone who had revocation checking in place was 100% safe as far as we are aware, not a bad record really.
There is a population of about 1 million certs out there, even 200 would mean 99.95% accuracy.
Running a CA is really boring work. Not something I would actually do personally. To check someone's business credentials etc takes some time and effort. It is definitely the sort of thing that you want a completer-finisher type to be doing. Definitely not someone like me and for 95% of slashdot readers, probably not someone like you either.
The weak point in the SSL system is not the validation of certs by CAs, they are (in order) (1) the fact that SSL is optional (2) the fact that the user is left to check for use of SSL (3) the fact that low assurance certificates that have a minimal degree of validation result in the padlock display.
The weak point being exploited by Iran is the braindead fact that the Web requires users to provide their passwords to the Web site every time they log in. I proposed a mechanism in 1993 that does not require a CA at all and avoids that. Had RSA been unencumbered I would have adopted an approach similar to EKE that was stronger than DIGEST but again did not require a cert.
Certs are designed to allow users to decide who they can share their credit card numbers with. That is a LOW degree of risk because the transaction is insured. Certs are not intended to tell people it is safe to share their password with a site because it is NEVER safe to do that.
Microsoft use open source code, but they only use code with licences that do not have a viral clause. They use some of my open source code in IE. Microsoft also publish open source code, but not under viral licenses. RMS is very definite about his intention to contaminate proprietary code with his own.
Now before folk go off into a slashweenie froth over this. I know RMS, i have argued this point with him. And he is very very clear about his intent that the gpl be viral. He makes no secret at all about this. Go and talk to him if you do not believe me. But dont assume that because the description of his idea sounds nutty that it must be false. Again, you need to talk to him and know him.
We expressly rejected the gpl for licensing the CERN web code because we did not want the ideological baggage. The code was merely a tool to spread the web. Well ok not for Tim, he hadvcode attachment, but not to owning it. We did make a big mistake in making the code public domain, but there was not the selection of licenses we have today. BSD would have been a better choice.
So dont blame Mr softy for taking RMS seriously. There probably isnt a legal risk there. But Gates is merely taking RMS seriously.
they have gone beyond protecting wikileaks and some are looking to replace them and set all information and secrets free.
Both groups belong in jail in my view.
That is why anonymous should be behind bars and so should anyone from Themis who has broken the law as proposed in this document.
the attacks proposed were against wikileaks, not just anonymous. There is no evidence wikileaks has broken us law. So this is not even vigilantism, it is a criminal attack.
The group proposed using disinformation tactics. So why believe their word now? Doing so without question seems naive.
Old programmers never die, they just branch to a new address.