> Ian Grigg wrote:
>> Good question. The answer: Branding. VeriSign
>> and other CAs would need to establish their brand
>> with the public. Verisign would need to act like
>> Intel or Coke or Ford and establish a brand that
>> speaks of trust.
>
> Isn't that just reinforcing the monopoly they currently have on SSL
> certs? And raising the barrier to entry for newcomers?
On a first order analysis, "branding" has that effect.
But, on further analysis of the economic effects of all
the factors, I don't necessarily think so. There are
these things that can be said:
1. The reason there is a strong dominating player at
the moment is because there is no way to compete. The
lack of branding is an indication of lack of competition,
not the reverse. Basically, the marketplace for certs
is primitive, "broken" in the techies lingo, and adding
branding would be one way to make it competitive. If
all of the elements were employed ("if PKI is fixed")
then the structure of the marketplace would be very
different. for example:
2. One of the essential fixes is to permit a graduated
array of cert protection. Currently the system is
binary; either nothing or CA-signed cert. What we
would desire would be a migration from nothing to self-
signed-certs to bargain CA-signed certs to heavily
branded CA-signed certs. The former market results in
more nothing, the latter market would result in a lot
more SSL being employed and more servers getting a lot
more protection, at a price point they can afford.
Which is to say that the market would be a lot bigger,
a lot more diversified, and there would be a lot more
protection. It is unlikely that a "monopoly" could
be sustained in such a market.
3. Incumbents don't currently do anything to justify
their brands, basically because they don't have to. If
they had to, there would be a shakeup in the marketplace.
Those that are small, lean and mean would be much better
placed to deal with the new branding issues than those
that are large, and encumbered with the baggage of past
mistakes.
4. Mozilla's mission is not to support or work against
any particular supplier of anything. It is - as I recall
from earlier discussions on the crypto list - to deliver
the best product it can for the average user. So, if
reinforcing the monopoly is the best way to secure the
traffic of the user, then that's aligned with Mozilla's
mission.
Which is to say, one should keep the mission in mind,
which currently I'd suggest reduces to: how do we
protect the user of Firefox from phishing?
(I could say much much more. But, in sum, the addition
of branding would not, IMHO, entrench any existing players.)
>> The problem is foistered on us somewhat by the PKI
>> design. At the moment, any cert signed by any CA
>> is assumed to be good by the software, but it's
>> pretty easy to see and to show that that is a really
>> bad assumption. Now, if we are going to have a PKI
>> where a CA is expected to be trusted, then that name
>> must be known by whoever relies on that trust (the
>> user).
>
> Or the trust has to be assessed by the user's software provider.
Right. Except, no software provider does that, or has
even thought about doing that, until Mozilla. And even
now, Mozilla does not, explicitly as of the moment,
assess the trust in the user's software provider.
What they do is check the WebTrust or equivalent. That
is "shifting the burden" or "passing the buck" depending
on which way you look at it.
At some point, Mozilla, under Frank's guidance, will run
out of the "easy" buck passing opportunities and start
to evaluate itself whether a CA should be added to the
root list. That's when the real security discussion
starts, because then we get to compare a WebTrust CA
versus a non WebTrust CA, and decide how much each is
worth, in security terms.
(This might be seen as an attack. It's not. Everyone
here, especially Frank, inherited the security layout
that is PKI and the root list concept from dim dark
memory. Now it is being attacked and breached by
phishing. It's important to understand that the current
PKI is broken, but it's just as important to understand
that it's not that hard to fix.)
>> It's a bit like if I were to sell you a can of
>> Coke that was coloured green. I say it's coke,
>> but you know something's wrong coz you've always
>> had familiar red cans. That signal should be
>> sufficient to get the average user thinking a
>> bit more.
>
> I suspect the average user would (if you told them) just assume it was a
> promotion.
Branding is very powerful. If someone passed off
a off a Subaru with a Ford logo on it, you wouldn't
be so easily fooled.
In the above case, most consumers would say, ah,
that's different, I wonder what the promotion is?
And they would pass a glancing eye over the cola
can to see. Not much of an eye, as after all, it
is just a can of cola. But, this would happen,
most of the time, and most people would pass to
the next step without realising.
That's what we have to do with the browser. Put
enough info on there such that the user can embed
in their brain sufficient neuron programming to
glance over the brand, without realising, and carry
on.
Bear in mind, the user also knows something the
developer and the architect don't know: they know how
important the information that they are being asked
to enter is; this gives them an inbuilt ability to
be more sensitive. In this sense the security model
of browsing is backwards, as it tries to create the
perfect security model so the user doesn't have to
do anything. That of course is impossible, there is
no perfect security.
>> Oh, this part is clear - it's based on the fact
>> that the user went to the site on their own volition
>> in order to open an account. They typed in the URL,
>> hopefully from some safe place. They have already
>> made a meaningful decision about their bank, all the
>> browser needs to do is relate that decision back to
>> right site, time and time again.
>
> I think it would certainly be good to have the UI indicate whether this
> was the first time you'd visited a particular SSL site or not. But that
> would require keeping a lot of history.
Yes to the former. To the latter? I don't know. I
think there are some low hanging fruit there, for example
the certs are already cached somewhere, and favicons are
cached. Amir and Ahmad already coded up their notions
in a Firefox plugin.
>> Bookmarks take a user to her site. Once there,
>> they disappear in relevance. The petnames suggestion
>> is that the name that the user labelled their bookmark
>> would be displayed on the chrome, quite prominently.
>
> So how do you solve the https://www.ibank.barclays.co.uk /
> https://www.barclays.co.uk / https://www.barclays.com problem?
I don't see the problem. The user sees that they
are different sites. She analyses the sites, and
if they are bona fide, enters different pet names
and carries on. When she gets phished over to
https://www.barclaysbank.com/ and finds that the
site might not be right, she doesn't petname it.
Have I got your description of the problem right?
As I see it, you are assuming that all those three
links are in some sense valid; when in fact there
is nothing backing up that assumption. And that
is precisely what the phisher wants, for the browser
to hide all the real information. So the problem
with the above is to stop assuming that they are
valid, and to insist that the user authenticates
them in some fashion or other.
(Now this is where branding comes in: if Barclays
have used Verisign for all their three certs, then
the branding of Verisign prominently on the chrome
will be consistent, and the phisher won't have that.
So the phisher has to trick Verisign into giving it
a cert. That's easy now. But once branding starts,
it will be hard; simply because Verisign will have
to start protecting their brand.)
http://iang.org/ssl/VeriCola.html
>> Yes, it would be a lot of extra stuff; but given the
>> SSL signal - this site is important - and the amount
>> of money being lost to phishing, then a fairly big
>> change to the way browsers think about user interfaces
>> is indicated.
>
> Do you have any evidence for "the big amount of money lost to phishing"?
Well, that's an important question, and it has bedevilled
the security field from the day phishing became a serious
endevour. My estimates from the middle of 2004 were about
a billion dollars.
http://www.financialcryptography.com/mt/archives/000159.html
Because each loss is small (order of $1000) and the
responsibility is not clearly allocated, it is very
hard to be precise. So we have to work on guestimates.
Now, consistently, for the last 6 months, estimates
have been coming in at 0.5 - 4 billion. Last week
there was an estimate that said something like "phishing
losses for 2004 will be $124.1 million" and that's the
only low ball estimate I've seen (as well as being a
particularly silly estimate, having 3 decimal places
of accuracy, before the year has even ended :-) .
So, I'm pretty confident that we can say "a billlion
dollars, and climbing."
iang
_______________________________________________
Mozilla-security mailing list
[EMAIL PROTECTED]
http://mail.mozilla.org/listinfo/mozilla-security
