Thanks, Peter. This dialogue is healthy. My point and the point that you and others have made is that whatever that number is we need to take it and boil it down to something manageable. If you cast your net in a way to identify a group of 650 (odds are there will be under-inclusion and over-inclusion), then we should take that sample and apply some additional criteria to the group. What problem are we trying to solve? Based on our answers to that question, we then design a sieve. For instance, if market forces are driving CA proliferation without quality control, then someone needs to identify what standards should exist and identify the bad apples based on some objective criteria. (From a positive perspective, what security measures can be implemented that will provide the greatest benefit and least collective harm?) The CA / Browser Forum and other groups are already working to make SSL more secure with things like the recent Baseline Requirements 1.0 (and future version 1.1, which will have more security requirements).
I don't disagree with you that it is harder to pick out a good or bad apple from a barrel of 650 than it would be if there were only 4 or 5 providers to choose from. But I'm not sure where the use of this number will lead us, if we were to say for example that most system operators could live with 20 or 30 CAs.? Facing multiple simultaneous risks is nothing new. In our everyday lives we rely, simultaneously, on more than 20 or 30 people to do things right--I'll face that just driving home on the freeway tonight. Are we driving toward some golden mean (10-20) or are we driving toward some acceptable standard of care regardless of the number? I am just advocating that we should try and identify any weak links in the chain, and strengthen or remove them, rather than focus on a large number like 650. I think this 650+issue will continue to get so much more flaming simply because it detracts attention away from the more difficult concepts that others like myself believe should be considered and remediated. I think some who follow the news of the SSL Observatory don't appreciate the inter-related complexities that arise with securing Internet communications and the balance that needs to be sought. To them it is easier to pull a figure out and say that the number itself is bad. The better approach, I believe, would be to devote time to those presenting the most risk and eliminate from review those CAs that just make it difficult to see the wood for the trees. So my point is that if I or someone else finds time, it would be a good thing to revisit the data (plus any additional data) and figure out a better representation for the problem. -----Original Message----- From: [email protected] [mailto:[email protected]] Sent: Wednesday, December 07, 2011 1:01 PM To: Ben Wilson Cc: [email protected] Subject: Re: Number of CAs Hi Ben, There have been some flames on this list about the number of CAs! We're certainly interested in alternative methodologies that might get a count that is more precise, both in terms of spotting multiple keys that live in the same HSM and also effectively have the same attack surface, and in terms of spotting CAs that aren't visible on public port 443. But I guess from my point of view this isn't the biggest research question at the moment. Regardless of what the count turns out to be, it just isn't going to be a number that's small enough for server operators to be comfortable if they need to defend against resourceful and determined adversaries. Honestly, I think a lot of server operators would be nervous if you told them that they had to simultaneously depend on 20 or 30 third parties not making errors, let alone hundreds. And as you know, the attack surface for domain validation includes not only N CAs but also N CAs' ISPs and their ISPs' routers. Where we hope the Internet community is moving is towards cross-checking protocols that mean that the number of CAs, or the possibility of attacks against their upstream networks, is not a security concern for TLS server operators. Lots of these are being proposed at the moment, and I guess the Internet engineering community is going through the process of trying to work out which are the most practical and desirable as both short- and long-term solutions. We have a long-term proposal that we've published (https://eff.org/sovereign-keys) that we'd welcome CAs' feedback on! There are also at least half a dozen other proposals out there, which have a great diversity of strengths and weaknesses, which this email is too short to do justice to. On Wed, Dec 07, 2011 at 11:56:58AM -0700, Ben Wilson wrote: > Peter, > > In an earlier post you wrote that the number "650+" for separate CAs came > from the number of distinct values for the "Organization" field in the DN > (out of more than 1500 CA certificates and 1200 DNs). Many of us in the CA > industry believe-from a purely objective standpoint-that the threat surface > in need of attention is smaller. Is anyone else besides a few of us CAs > interested in analyzing this same general area (number of CAs) with > different criteria in mind? If the PKI hierarchies involved and physical > location of CA keys were considered, then different conclusions could be > made. For instance, what would the map look like if the DFN-Verien root > were removed? It's just that the number "650" is now being used regularly > in various venues to argue that the problem is that there are too many weak > links-but while there may be a statistical correlation (the more cars there > are, the more likely you are to get into an accident), the large number > alone does not lead directly to the conclusions being made. As someone > mentioned to me recently, it's just a number, but what it connotes might be > something more and statistics and visual representations support the case > one tries to make. All I am saying is that a number alone only tells us > "how many" - it doesn't tell us anything about "good" or "bad." In other > words, a purely quantitative analysis without corresponding qualitative > criteria brings about a different result and leads to a different conclusion > than what course of action might be best. Just some thoughts. > > Ben > > > > Benjamin T. Wilson, JD CISSP > General Counsel and SVP Industry Relations > DigiCert, Inc. > > <http://www.digicert.com/> Visit DigiCert.com > > Online: <http://www.digicert.com/> www.DigiCert.com > Email: <mailto:[email protected]> [email protected] > Toll Free: 1-800-896-7973 (US & Canada) > Direct: 1-801-701-9678 > Fax: 1-866-842-0223 (Toll Free if calling from the US or Canada) > > _____ > > The information contained in this transmission may contain privileged and > confidential information. It is intended only for the use of the person(s) > named above. If you are not the intended recipient, you are hereby notified > that any review, dissemination, distribution or duplication of this > communication is strictly prohibited. If you are not the intended recipient, > please contact the sender by reply email and destroy all copies of the > original message. Thank You > > > -- Peter Eckersley [email protected] Technology Projects Director Tel +1 415 436 9333 x131 Electronic Frontier Foundation Fax +1 415 436 9993
smime.p7s
Description: S/MIME cryptographic signature
