Frank Hecker wrote:
[I have snipped large parts of the original.]
To repeat: From a technical point of view the "one tooth"/"two teeth" UI difference (one for 40-bit, two for 128-bit) was simply a distinction regarding key length that arose from external factors (i.e., US encryption export regulations). No one deliberately sat down and said "We'll design SSL to have a 'good enough for banking' mode and a 'not good enough for banking' mode, and we'll choose 128-bit encryption for the one and 40-bit for the other."
The US gummint imposed export controls. The crypto people themselves believed that 40 bits wasn't good enough for anything of real value, including banking. The crypto people chafed at having to ship something tht they themselves thought was not good enough for people to entrust with their security needs. In their way, they rebelled against it. So, they devised the 1 or 2 toothed key as a way of conveying to users a message about that. 1 is better than none, 2 are better than one. The message was intended to be "one is not good enough", and "two are good enough". That was the designers' intent.
They didn't do that because export controls required it. Export controls did not require ANY UI to express anything about the use of crypto whatsoever. The crypto designers wanted to provide a non-binary indicator to users, to give them a hint that not all protection is equal. They were forestalling the binary lock icon, because they saw the situation as truly non-binary.
And the banks drove that point home.
And for US banks there was little or no cost in mandating use of 128-bit encryption, so why not do so? (The only real impact would have been for US banks with non-US customers, a fairly small group.)
No, download records showed that many users, even in the USA, downloaded only the weaker export browsers. Remember that in those days, users had to click on a page in which they agreed to a number of specific things (such as that they were "US persons", on US soil, and would not export the software to "non-US persons". That scared off a lot of people.
Banks in the US were the ones who started the "not good enough for banking" business. Lots of US persons had to go back (after they had already spent 5 hours downloading the browser on their 56k modem) and do it again to get the other browser, because they couldn't bank online otherwise.
By the time the liberalization of US export regulations ended the need for 40-bit, the equation "(128-bit) SSL means 'secure for banking'" was firmly fixed in people's minds, as it remains today.
I agree with that.
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.
then running into trouble trying to attach firm fixed meanings to those distinctions. More specifically: On the one hand we have certificates (specifically SSL certs) that are issued after a particular type of CA process, a process (typically automated) that verifies the suscriber's control of the domain associated with the cert. On the other hand, we have SSL certificates for which the CA's processes also include additional checks (some automated, some not) through which the CA purports to verify the claimed real-world identity of the subscriber.
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. I wouldn't advise anyone else too, either.
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?
(commercial) CAs are motivated to reach a new class of more price-sensitive customers (because their traditional business has reached a plateau) and reaching those price-sensitive customers requires achieving cost efficiencies, which in turn can be done through the introduction of increased automation and taking humans out of the loop.
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?
Or is it to preserve the trust of the users? Maybe we have to say no to a few CAs to preserve that trust.
[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 do need those who can give us high assurance that the party holding the private key for this cert is really your bank, and not Joe's MITM marketing agency or Jane's MITM ISP.
IMO it's more that the distinction between different types of certs *could* be made on technical grounds (having to do with different cert issuance processes) and having done that it's then tempting to attach fixed security-related meanings (e.g., "low/high assurance") to the distinction.
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?
[big snip] My purpose in doing this is to try to think through my strawman UI proposal earlier (to replace the binary "no SSL"/"SSL" UI with a more multivalued model) and to try to improve it and address some of the objections to it.
In particular, one of the main objections to the strawman proposal is to the division of CA certs into "high assurance" certs (for which the padlock is displayed) and "low assurance" certs (for which something else is displayed), on the grounds that such a division isn't actually valid or straightforward to do. I think those objections are worthy of a serious response, and any realistic proposal has to take them into account.
I think I previously described it as a cost associated with that choice. All choices have costs.
So what's the alternative? One alternative is to retain the division of CAs and certs into two (or more) classes for purposes of the UI, but not go overboard in presenting this as a "low" vs. "high" distinction. For example, we could make a UI distinction between "control of domain" SSL certs and "claimed identity" certs, but in presenting this to the user (e.g., in informational messages and the like) we would simply present the technical distinction and not editorialize about "trust", "high assurance", "safe for online banking", and the like.
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.
(So, for example, when a user is presented information about an SSL-enabled site with a "control of domain" cert issued by the Foo Class 1 CA, Firefox might display something like "The site you connected to has the domain name 'www.acmewidgets.com', as verified by the 'Foo Class 1 CA' independent service", while for "claimed identity" certs Firefox might display something like "The site you connected to has the domain name 'www.acmewidgets.com' and is operated by 'Acme Widgets, Inc.', as verified by the 'Foo Class 1 CA' independent service.")
I think that's a valid distinction in its own right. 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.
-- Nelson B 12345678901234567890123456789012345678901234567890123456789012345678901234567890 00000000011111111112222222222333333333344444444445555555555666666666677777777778 _______________________________________________ mozilla-crypto mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-crypto
