No, download records showed that many users, even in the USA, downloaded only the weaker export browsers.
Fair point, but I still contend that forcing US users to go back and download non-export browsers was not a cost on the bank, but rather on the bank's users; in other words, the banks could externalize the cost. But in any case that's a minor point not IMO worth debating further.
Now, what does this have to do with the present discussion? Simply this: we are again dealing with technical distinctions first and foremost,
I don't agree. Security work is never technical first and foremost. No-one who works in this area does so out of some sort of intellectual purity of technical goals. It's done to give users real security.
I'm not disputing that. My point is simply that one can approach the goal of security in multiple ways, each of which has its place. One way is to focus on the entire space of possible threats and devise ways to counter those threats; the goal is to have a "prevention mechanism" for each and every of those threats, and often these mechanisms are such that they can be parameterized in some way, e.g., varying key lengths, or varying degrees of rigor in vetting cert applications. As you vary the parameters it's natural to think of moving along a spectrum from "low security" to "high security" and vice versa, and it's also natural to think that the goal of providing "real security" to users is best served by setting all relevant parameters to the highest possible settings. It's this way of thinking I was referring to when I referred to "technical distinctions" and attaching security-related meanings to those distinctions.
Another possible approach is to look at security as a risk management problem. To quote Christopher Allen from his blog post at
http://www.lifewithalacrity.com/2004/02/security_crypto.html
this approach "balances the risk of a bad outcome, the cost of that bad outcome, and the cost of reducing that risk. Even if a system is technically insecure, [people can] accept it if the risk of a security breach is low, the cost of a security breach is low, or the cost of closing that breach is high."
My point was and is simply that I don't believe that the people who originally developed the CA system and the associated X.509v3 PKI took a risk management approach based on an economic cost/benefit analysis. I think they took the approach of cataloging potential threats, conceiving of counter-measures, and parameterizing the measures where they were able to do so, e.g., by defining different standard key lengths, defining various levels of CA vetting, etc. In some cases they aligned particular parameter settings with particular contexts of the legal infrastructure of e-commerce for which PKI was envisioned as an enabler.
Ram did make a good point that the legal system has evolved in a way that embodies some level of cost/benefit analysis, and thus by aligning with the legal infrastructure a risk management approach did influence the development of CAs and PKI. I'll concede this, but only so far, because a) the influence was only indirect, and b) the legal issues considered were primarily those associated with e-commerce, and not necessarily for other PKI use cases.
Again, this is just my supposition; if I'm wrong, and someone somewhere has done a complete economic/risk management analysis of CAs and PKIs I'd certainly be interested in reading it.
So, Frank, there are new CAs that want to issue certs with less and less verification. I wouldn't trust a cert from most (perhaps any) of these "domain control" CAs for anything as serious as banking.
And I'm not asking you to; however see below.
What should mozilla do? Should mozilla strive to admit all comers, and watch as the level of trustworthyness of PKI erodes to the point where people can no longer know if the connection is good enough for banking based on the info presented in the browser UI?
First, in your terms the level of trustworthiness is already eroded and has been for several years, since that's how long "low assurance" certs have been issued and have been recognized as "trusted" in standard browsers (Netscape, Microsoft, Mozilla, etc.). (Actually, note that Thawte and Go Daddy refer to their SSL123 and TurboSSL certs as "medium assurance", not "low assurance".) Thus I believe your statement could leave people with a false impression: that things are OK now, but won't be OK anymore if we fail to adopt a suitable policy.
"What should mozilla do?" I think the MF should do two things:
1. Have a CA policy that does *not* "strive to admin all comers", but rather puts various reasonable requirements on CAs, requirements that are consistent with existing CA practices, which include issuance of different types of certs with different issuance processes. In plain English, that means that the policy can't simply reject CAs that issue "control of domain" certs or other "low/medium assurance" certs, since these are in common use already.
2. Consider changing the SSL UI to introduce a UI distinction between SSL connections involving different types of certs.
I have a fair amount of influence over the policy, but little influence over the UI; for UI issues you're better off lobbying Gerv.
Now, the question for mozilla is, what is our goal? Is it to admit as many CAs as possible? Is it to create as large a market as possible for all the CAs, including the ones who who don't want to charge enough to cover the costs of doing a good job of earning trust?
As stated in the original metapolicy document I created, I think our goal should be to achieve a balance between the benefits and risks of including new CA certificates, with benefits being those associated with increasing the security of services used by at least some users. That implies that promoting wider use of SSL is in fact desirable, since there are several use cases where users could benefit from SSL but currently do not. However per the metapolicy such benefits have to be balanced against the risks incurred by typical users doing personal tasks involving some level of risk, e.g. online banking, e-commerce, etc. This whole discussion is about balancing benefits and risks, *not* about avoiding risks per se.
Your opinion (as I understand it) is that the benefits of wider SSL use in general are outweighed by the danger of "watering down" the perceived protections SSL provides to online banking and e-commerce, and that we should in effect ban use of lower-assurance SSL certs (as might be used for non-banking/e-commerce purposes) in order to protect the use of SSL in banking/e-commerce.
My opinion is that those protections are already "watered down" and have been for many years, so you are "trying to close the barn door after the horse has been stolen", to use the colloquial phrase. I would rather acknowledge that reality, continue to accept and promote the use of SSL in non-banking/e-commerce contexts, and look to UI changes if we feel a distinction between the uses is called for.
Or is it to preserve the trust of the users? Maybe we have to say no to a few CAs to preserve that trust.
We have already said no to some CAs, and we'll say no to more of them in the future. But I am not willing to summarily reject CAs based purely on the fact that they are issuing so-called "lower assurance" certificates, particularly since such CAs have already been in the CA list for some time with no apparent problems (and hence no impact on the "trust of the users").
Now, having said that, I am perfectly willing to impose other requirements on CA, like issuing technically correct certs, operating to particular criteria, putting a "floor" on acceptable vetting of subscribers, and the like. I'm happy to take suggestions on this from you and others.
[snip] I doubt that anyone did a thorough security analysis and concluded from that analysis that we absolutely needed two (or more) types of certs and associated cert issuance processes.
I agree. We do not absolutely need two or more types. We do not need low assurance CAs at all.
We'll just have to agree to disagree on this point. I presume CAs do not agree with you either, nor do their customers; otherwise CAs wouldn't be offering such services and customers wouldn't be taking advantage of them.
Are you saying that the difference between CAs that verify their appliciant's identifies and those who do not is merely a technical distinction? A technicality, not correlated to assurance or trustworthiness?
No, I'm not saying that; see my response to Ram, for example. Maybe an analogy will help here (and I will apologize in advance for perhaps seeming to lecture you about things you already know):
Go back and read my comments above about "parameterized security". Now consider key lengths as used in encryption algorithms; clearly this is a parameter that can be varied, and it's tempting to assume a priori that longer key lengths mean higher security, and lower key lengths assume lower security. It's also tempting to assume a priori that achieving "real security" requires choosing the longest key length possible (within the constraints of the algorithm).
But: longer key lengths don't always mean more security; this depends on the design of the algorithm. (For example, there may be ways to break the algorithm that require less time than brute force key search, with increases in the key space not affecting the time to break.) Similarly, it doesn't necessarily make sense to always choose the longest possible key length; it's possible that a medium-length key will serve perfectly well.
How then do people make decisions about key length? They look at the work necessary to break algorithms, given algorithm design, key space size, known attacks, resources available to attacker (e.g., CPU speeds), and related factors. They then balance that work against the risks present in the actual use case of interest.
My point is simply that we have to treat CA issuance processes (i.e., what supposedly determines "cert assurance") the same way. We can't simply assume *a priori* that a particular "higher assurance" issuance process provides more security in practice than does a less rigorous "lower assurance" process, nor can we simply assume a priori that achieving "real security" requires the highest possible assurance in CA issuance processes.
As with key lengths, someone actually has to look at the work necessary to "break" CA issuance processes, given the design of those processes, known attacks, resources available to attackers, and related factors, and then balance that against the risks present in the use cases of interest.
Has anyone actually done such analyses? If they have, I'd certainly be very interested in reading them.
If users cease to have a clear indication of "good enough for banking", I would expect banks to react to that, not with another user education campaign, but by refusing to work with those browsers and their tiny market shares. Some banks already do this.
Nelson, I hate to repeat myself, but according to your definition users today don't have a "clear indication of 'good enough for banking'" in the browser with the dominant market share, since to the best of my knowledge IE will happily display a padlock for a site with a "control of domain" cert issued by any of a number of CAs.
No CA should ever certify information they haven't validated. The challenge is to ensure that the control-of-domain CAs don't issue certs that include the unverified "Acme Widgets, Inc." in the name.
That's a reasonable position to take, but my question from my previous message remains unanswered: If an SSL cert should use subjectAltName for the domain name instead of CN, then what information should a "control of domain" SSL cert use for the subject? (As a point of interest, Thawte and Go Daddy, to name but two CAs, are still using CN for the domain name, and if you don't define O, OU, etc., then they will stuff in text like "domain validated" and the like in those attributes; more on this in a future message.)
Frank
-- Frank Hecker [EMAIL PROTECTED] _______________________________________________ mozilla-crypto mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-crypto
