Now for MAJOR point #2. What is the definition of "assurance" ? And what is meant by "high assurance" ?
Luckily Frank dives right in here below and defines "high assurance."
Frank Hecker wrote:
* A "high assurance" certificate can be defined at a high level as "a certificate issued only after some level of human review of the cert subscriber", whereas a "low assurance" certificate might be issued through an automated process, e.g., one that simply verifies that the cert subscriber controls the domain listed in the certificate. With a low-assurance cert we can assume there is some basic protection against certain types of phishing attacks (e.g., attacks based on DNS spoofing), but we don't necessarily want to give the user the impression that the site is in the same category as traditional e-commerce/financial sites where they've been conditioned to look for the padlock.
Out of the above, I see these things:
A meaning for "high assurance" certificates is:
"is a traditional e-commerce/financial site."A test for "high assurance" certificates is "human review."
A meaning for "low assurance" certificates is that
the domain is as it says it is.A test (of sorts) is that the issuance is automated.
That's a little bit strained, but might do for now.
The issues then arise that actually, these definitions don't buy you enough to be worth the effort. For example, imagine I want to start selling high assurance certs for $10. If the test is human review, I simply employ nepalise school kids to do a bit of browsing and reading of faxed documents.
Alternatively, imagine we live in the future world of strong identity tokens, like they do in some countries in Europe.
http://www.financialcryptography.com/mt/archives/000249.html
So, with a little bit of jiggery with smart card readers and so forth, I can set up a system that issues individual level certs to people who over the net plug in their smart card, sign the request and get the delivery sent to their secure email address. Not only have I got reliable chain from smart card to email delivery, I also have the law backing me up, as once signed by a smart card, it is an accepted signature and contract.
Hey presto, I can set up a "high assurance" certificate delivery system and I can automate the lot. I know it is high assurance because every step along the way is high assurance, the linkages are high assurance, and the courts are high assurance.
OK, so having broken the meaning and the test (sorry Frank!) why is this? Well, it relates directly to the failure to define "assurance". Unless assurance is defined, there can be no meaning to "high assurance" and no tests. Hence, although the meanings and tests can be imagined and proposed, the only thing we have to go on is gut feel. Does it feel right? As an example: "automation is too easy ... so it must be bad for high assurance, right?" Well, maybe.
_The challenge then is to define assurance_. This is really tough. The obvious problem is that assurance depends on who and when we are talking about. Is it:
* Lazy lina who is buying a book from amazon?
* Dodgy dan who is surfing porn with his wife's credit card?
* General Jim who is just sneaking back to the NSA so as to
up load his night's work on the latest threats to the nation?
* Teenaged Timmy who's chatting with his girlfriend and trying
to score without his kid sister peaking and spoiling everything?
* Crypto Che who's sending the plans for the rebel attack to the
revolutionary high command?All of these contexts result in highly distinct threat scenarios. SSL "covers them all." What is high for one may be low for another, and vice versa.
As we know, the imposition of the binary security model has a difficulty in the real world of browsing.
In practice, it cannot find peace in any "high assurance" model, as there is no way to deliver that "high assurance" to all those people. It *can* find peace in the "low assurance" model, but only by settling on the lowest common denominator - the least protection.
Which annoys everyone. Hence the demands for "high assurance" but these demands simply repeat the conundrum - how to define "high assurance" and more basically, what is assurance?
Replacing a binary security model with a ternary security model does not solve the problem. It does one thing for us, which is to isolate and point fingers at the problem ... but that isn't enough to solve it.
So in order to define assurance, we need something hard:
The reason for making the "high/low" distinction depending on the presence or absence of human review is that this is directly related to the cost (in time and/or money) of doing phishing attacks that direct people to SSL-protected sites. Just as the low cost of domain registration allows phishers to register "throw-away" domains for their sites, evading anti-phishing defenses based on flagging URLs that contain IP addresses instead of domain names, under the current UI model the relative ease of getting low assurance certs means phishers would be willing and able to get "throw-away certs" for their throw-away domains so they could show the same padlock that users associate with e-commerce and financial sites. Reserving the full "SSL treatment" (i.e., with padlock and possibly yellow location bar background as well) for sites with "human reviewed" certs means that the incremental cost of setting up a complete "look-alike" site would be high enough to discourage doing this for throw-away domains.
OK, this is getting closer to a rationale of economic security. For the phisher, there is only one question, which is how much does it cost me and how much do I earn?
For the security defender it is much harder, as spending money on X when Y is weak is a waste. He must come up with a balanced approach where money is spent on the weakest components, and saved on the strongest components. (This is why for example 40 bit crypto is entirely adequate to most purposes: for the attacker, it is cheaper to buy a $30 cert from some CA than it is to build a roomful of crypto crackers.)
The problem then is for the defender to say "how much is this cert worth?" The relying party and the cert owner both have the same question. Now, the question is *not* totally answered by "how much does it cost?" As I described above, the cost of production of the cert is only a very weak indicator of how much it is worth.
The best way to answer this is to ask how much the user gets when the cert is breached. Hence, what the recent European CA was doing was a step in that direction - displaying the Euro amount. In this direction, we want to say with the cert: how much do you insure me for my loss? How much does the user get when she is phished?
Is it $1000? $10,000? Or $100?
Those are hard comparable number. That number can answer "assurance" to some degree. This is about the best answer that exists.
And now, Frank asks this:
> * How would we decide in practice (i.e., at runtime) whether a given > cert was "high-assurance" or not? Since this is not directly > determinable from the information in the cert itself, we'd probably have > to maintain a mapping from the stored CA certs to a "high/low" value. > For certs in the default set the high/low value would be assigned at the > time the cert were added to the default set, in the same way trust bits > are assigned now, and our CA cert policy would have to have some > criteria relating to high/low assurance. For certs added by the user the > assurance level could be set by the user, with low assurance being the > default. (Or if we want to be draconian we could arbitrarily decide to > mark user-added certs as low-assurance only.)
Right. So along my above lines - assurance means dollar insured value for relying party - how do we determine at runtime what this means? A very key question, because the user has to rely on something in real time, otherwise it is meaningless.
And here's where it breaks down:
The browsers and certs and CAs are not in a good position to employ this. Witness the European CA certs that included the critical bits; the infrastructure to benefit from this answer is simply not in place.
Which leaves us getting back to "what is assurance?"
Unless there is an answer to that, the proposal lacks ... foundation. It would be telling users more stuff that they don't understand, and they cannot rely upon. So it will be more confusion, and more baggage to clean up later.
iang -- News and views on what matters in finance+crypto: http://financialcryptography.com/ _______________________________________________ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
