Nelson B wrote:
4. (recent addition) certs used with phishing, including:
- certs with names confusingly similar to other domains, e.g.
paypal-security.com
- certs with IDN/punycode names that look like well known names
but aren't exactly.
One might add to that category:
- certs with names that are confusing but have no
apparent hook to the target: compliance-center.com
Or maybe it's a new category.
> Second, you seem to be saying that under the past and current policies
> for adding certs to the Mozilla default set (as implemented by Netscape
> and then myself) there has been minimal issuance of "duff certs"
> (however defined), but that under the proposed new policy the issuance
> of "duff certs" could be substantially increased. The implies (at least
> to me) that such an increase in "duff certs" would be specifically
> caused by adopting the new policy, to the exclusion of other
factors. Am
> I reading you right here?
Yes. Now before I respond to any more questions, I must speak to the
"binary UI security model", because it is crucial to my answers.
Sorry if this is a bit long winded.
Today, the mozilla products have a binary UI security model. The padlock
is either open or closed. Period. And for SSL, users understand the
closed padlock to mean "good enough for banking". In other words,
high assurance *and* strong crypto.
As long as that remains true, ...
Unfortunately "users understand..." is not true and demonstrably
not followed. Phishing tricks lots of people. Not all the users
check the padlock. Whether this is 10% .. 50% .. 90%
of users of banking ... I don't know. Whether we can
"save" them I also don't know.
What is true is that the binary UI security model is
essentially what's on offer today, modulo various
improvements in the the recent flush of browsers.
as long as the padlock is either open or
closed, and no other info is presented to the user IN THE MAIN WINDOW
on which the user can judge the quality of the cert/CA, then IMO the
standard for closing the lock on a web page is, and must remain,
"good enough for banking", and "high assurance". It would be UNETHICAL
for us to allow low assurance CAs to be treated identically to high
assurance CAs (appearing to be "good enough for banking"), yet the
present UIs provide no way for a distinction to be presented.
OK, I see where you are going. In the face of the
facts that a) the padlock is not often checked, and
b) that it is easily bypassed by non-SSL phishing,
I personally wouldn't be comfortable with any
argument that relied on the padlock as a standard.
Given, c) it is apparently easily bypassed for SSL
phishing (c.f., Shmoo), I would say that the padlock
only represents your "low assurance" grade.
MAJOR POINT, that binary UI model is strictly the result of UI decisions
made by the browsers, and not the result of NSS. The UI people MUST
be willing to devote more screen real-estate to security info before
the binary security model can be eliminated.
Yes. I think we are all agreed on that. It's for
this reason - that tough painful statement - that
we are somewhat stalled on this until some
MF wide approach is taken.
[Toothy history chomped :]
a) go back to a iconic model that has clearly 3 or more states, which
are OBVIOUS to users in the chrome of the MAIN WINDOW, without the user
needing to click or move the mouse to see the info,
The problem with this is that while you suggest that
the 2-n extra states had semantic meanings like "good
enough for banking," no such real security statement
applied. Historically, this was a case of the crypto
warriors capturing finance as a pithy way to say that we
wanted 128-bit-or-die. But in actual security systems,
it makes no difference whether it is 40 bit or 128 bit
for banking as an application. The difference in security
for banking is all in the CA and cert and identity questions,
and not in the strength of the on-the-wire crypto.
b) go to a model that identifies the CA, and allow the user to decide
for him/her self whether the CA is high or low assurance. The CA could
be identified by text (a name) and/or a "FavIcon" as web sites are now.
The browser could help the user remember his decision, and allow him to
change it.
The first method is visually the most simple, but requires someone to
make a judgment call on the user's behalf concerning the assurance
level of the CA. I think this is least confusing for the users, but
more work for MF and NSS.
Yes, this is true as well. Not just more work, but also
more involvement than is advisable. Also, given the
contentious nature of the statement that it's good
enough for banking, that suggests non-trivial risk.
The second method requires the users to grow their awareness of CAs
(of which they know nothing today). It also requires more window
real-estate. But it keeps MF out of the judgment business, which is
a business that MF seems particularly loath to do.
Yes. It is somewhat the case that there is no painless
way forward. Someone somewhere is going to hurt.
....
Now, why is this? Why is the distribution of problem certs so one sided?
Perhaps the CA operators with money at risk want to take the time to
get it right, and the freebies want to cut corners to remain low cost.
Perhaps the CAs with money are able to hire people who have learned
the standards and appreciate the value of standards conformance,
while the freebies think that OpenSSL *IS* the standard. :(
My point is this: the past policies of charging money or requiring a
stamp of approval that costs money have (IMO) served the mozilla
community
well, in terms of keeping "duff" certs out. MF has not historically
set forth my "duff" criteria above, nor required that CAs avoid them,
yet magically, mozilla's trusted CAs have managed to rarely issue
duff certs!
This is potentially true. Problem is, this "barrier to entry"
as it is known has also served to keep valid cert usage
down as well.
It will simply be a disaster if more duff certs start to be encountered
by mozilla users in large numbers. In the past I have replied to
hundreds of bugs reports by ignorant OpenSSL users who accused mozilla
of being buggy because their invalid certs didn't work with mozilla.
But I'm all done with that. I simply won't do in any more.
If issuers of duff certs are admitted, the flood gates will open.
products associated with a list that includes duff issuers will be a
laughingstock.
Frank, will *YOU* answer all those bug reports, explaining what's wrong
with their certs? If not, who will? Not me.
This is definately an issue. I'm not sure I see it as
a killer issue though, it seems that this sort of issue
exists with all software.
Now, I want to summarize this. IMO, it turns out that COST has been the
only factor responsible for the apparent success of PKI, having kept the
issuers of duff certs out, and having allowed the issuers of good certs
in. It wasn't the WebTrust criteria that kept them out, it wasn't the
ETSI TS 101, it wasn't nosy auditors, it was cost.
Well, I have a different perspective. As you know,
I consider PKI to be a stunning failure, partly because
it is so expensive that its usage rates are down in the
noise level, and partly because it set itself up to defend
a threat that never eventuated. That isn't the CAs
fault. Well, maybe, maybe not, but the blame game
helps no-one.
What we have now is that the PKI is in place with all
browsers and all web servers. That's a fact. So it is
the starting point to addressing the security failure
of secure browsing. We can use the PKI certs to deal
with phishing to a substantial extent, but it requires
some changes...
Getting back to the cost issue. If we decrease the
cost of certs, then we decrease the cost of duff
certs. I'd hazard a guess that the cost of a duff
cert (for phishing) is about $100 - $1000; this will
lower it to $10, say. As phishing is pulling in a billion
or so every year, I don't see this as a big deal.
However, what is a big deal is how we move from
"no user interaction" to "user-based security model."
Lowering the cost of all certs will help that. I think
it will focus attention on the problem, and the faster
that happens, the better. Preferably faster than
the phishers switch to SSL; as once they do that,
the waters get very murky very quickly. IMHO.
Regarding phishing: Phishing is merely one aspect of the problem of
lack of authentication with network peers. A victim of phishing is
dealing with someone over the net, while having a mistaken understanding
of who he is dealing with. This is the same problem as the MITM attack
presents, exactly the same. You think you're dealing with Alice, but
you're dealing with Evil Eve.
Right.
At the same time that phishing (one form of attack based on inadequate
authentication) is getting so much press, some who tout SSL to be a big
part of the solution have also called for allowing self signed certs to
be treated as equals with certs from high assurance CAs. Oy!
:-) I detect my name hidden there. I think the
debate over self-signed certs is way too complex
for here, so I've left it alone. A full security
analysis of the self-signed cert v. CA-signed
cert is a rather complex business, and not
helped by the heated opinions.
But one can say that they are not equal and
should preferably not be treated as equal.
(Presenting both self-signed certs and CA-
signed certs to the user would be one way
in not treating them as equal!)
iang
PS: This also is a rushed post, I'm in Austria
at the moment, and happen to be jacked in at
the offices where the NSA scandal broke. A
total accident, I assure you! Here, it is huge
news, we are currently listening to a long
interview on national radio about the NSA,
but it's in German and therefore I can only
hear the remotest snippets.
While I'm on the subject, those who are interested
in the identity debate should check out the story
because the breached information includes a lot
of political background. Search on "datamining
the NSA" or check slashdot.
--
News and views on what matters in finance+crypto:
http://financialcryptography.com/
_______________________________________________
mozilla-crypto mailing list
[email protected]
http://mail.mozilla.org/listinfo/mozilla-crypto
