Frank Hecker wrote:
Ram A M wrote:
Hmm, posted a response earlier today - I'm trying again as it's been
hours and hasn't shown up.
Actually, I did see your earlier post, reading it off of the
news.mozilla.org news server.
I saw it too, off the maillist.
In general I think we agree more than we disagree, and in many cases are
aggressively in agreement, so I'll confine my followup comments to one
key point.
(Agreed!)
I don't know how many levels of bars there needs to be but I see a risk
to the user in presenting the less robust or lower auth offerings to
the user in such a way that they recognize it as a 'safe for banking.'
This I think is the key question we need to look at: How to
differentiate different types of SSL/TLS applications (low assurance vs.
high, banking/e-commerce vs. "casual" use, etc.) while not either
violating user's existing expectations or overly confusing users.
One approach proposed is CA branding, so that the user makes
distinctions directly based on the CA-specific information presented to
them (logo, wordmark, whatever). See Ian G for details :-)
I stand ready to rant on command :)
Another approach is to provide some sort of UI indicator that is a proxy
indicator for the level of assurance. For example, in an earlier message
to this forum Gerv proposed using a "site identity verified" message in
the status bar:
> Site-ID-verified-by-DNSSec: "site identity verified" indicator
> low-assurance cert: "site identity verified" indicator
> high-assurance cert: lock and "site identity verified" indicator
This proposal is actually quite radical, since it would abandon the
traditional use of the lock to indicate an SSL connection, and reserve
the lock for use only with certain types of SSL connections, i.e., those
made with "high assurance" certs (suitably defined). Other SSL
connections would *not* show a lock.
Radical though it might be, something like this might actually work.
However rather than using the phrase "site identity verified" (what does
this actually mean to users?) or some other textual message, why not use
a different graphic, like a check mark? Users would then be free to
build new expectations: Seeing a check mark is a good thing, but if
you're spending money you'll want to see a lock as well.
In this case to avoid confusing users I would reserve the check mark
only for SSL/TLS connections, since I think part of the user
expectations would be some level of confidentiality of communications.
That would also be part of the marketing message for CAs trying to sell
low-assurance certs to new customers not concerned with financial or
e-commerce applications.
There are two approachs with the padlock, as you suggest:
the high road and the low road. The problem with the low
road is that nobody is happy with the perception of
lowered security. The problem with the high road is that
VeriSign aren't going to agree that Comodo's high-ass certs
are as good as the VeriSign ones. And, to a large extent
they have a point; there is no reasonable way to compare
certs at the high end, as a lot of care is taken to
decommoditise the product as more money is paid.
Of the two, I'd prefer the low road: padlock signifies
that a TLS connection is in place.
I think this matches the "pure view of TLS". The purpose
of the cert is to simply stop the MITM, so the domain needs
to be checked only. Hence Ram's "control-of-domain" term.
<rant>
The "expanded view of PKI" is that the identity information
in the cert is valid. That's a lot more problematic to
rely upon, as, in security business we have no great theory
of identity. Ellison&Schneier for example points out that
there is no great or strong reason to believe that a cert
signs on behalf of an individual - notwithstanding many laws
and products that rely on this concept. My own critique is
more software driven: Identity often drives the requirements,
but it can never be the application, so everything appears
backwards.
Yet Identity is what the assurance model promises. Given that,
pragmatically, anything that a browser can do to narrow down
the claims of identity and matching assurance statements will
help enourmously.
There is an even further step beyond, which might be called
"the trust view." That is, if the padlock is on, you can
trust... This is hopeful at best and will lose the client
money at worst, simply because trust is an undefined concept,
and thus is oversold. In the security community these days,
we tend to perceive the word 'trust' as snake oil; if you
can't describe your claims without using the word trust, it
is likely you don't know what your claims are, and you are
just hoping the listener doesn't notice.
</rant>
Otherwise there'd be no distinction to the user between encrypted SSL
connections using low-assurance certs and unencrypted connections to
sites with domain names verified via DNSSec. I know some would argue
that SSL connections using low-assurance certs are indistinguishable
from non-SSL connections from a security point of view, but I don't
think treating them exactly the same from a UI perspective serves the
interests of anyone, least of all users.
Right. Which still leaves (sorry to bring this up) the
oddball meaning of a self-signed cert. Where this gets
interesting is that when it first appears, it signifies
a secure connection albeit with a minor risk of MITM.
But, if the user then accepts that connection, and if
she could record that acceptance, then follow-on connections
would potentially deserve the padlock. Still, let's ignore
that for now...
iang
--
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
