Re: ACTION-240 :TLS errors...

Okay, hopefully this is better articulated:

Everyone who has said something about this issue is thinking as an IT
expert.  You're not thinking like an end-user.

If you encounter a website that contains an expired certificate, what do
you do?  I highly doubt you apply one decision (i.e. "continue to
website" or "go somewhere else") to all such situations consistently.
This is a very subjective decision.  As an expert, we see these warnings
and then take other factors into account when determining whether to
submit information.  The average end-user does not do this.  The average
end-users will see the warning, glance at the page in the background,
and if the site "looks" authentic, they will ignore the warning.  The
average user cannot make an informed decision in this situation because
they do not have the domain knowledge (no pun intended).

In such situations, you need warnings to interrupt the user's task, and
convince them that proceeding really isn't a good idea.  However, for
such warnings to be effective, they need to be used rarely!  Otherwise
you start having to deal with habituation, and we begin training users
to ignore these new warnings.

Therefore, if we're going to talk about making effective SSL warning
messages, we need to narrow down the situations in which they'll be
used.  Sure, you're absolutely right, there are risks to visiting sites
with SSCs, I'm not disputing that at all.  However, the probability of a
user being exposed to these risks are miniscule (all things being
relative).  We need to put all of these threats in perspective when
determining when to display warning messages, because again, if we warn
about every conceivable risk, the warnings become useless.

Think of it this way: if you see a warning, as an expert, that asks you
to make a very subjective decision, how reasonably well should we expect
the average AOL user to make that same decision?  Will the average user
inspect the certificate?  Does the average user even know what a
certificate is?  If we're going to be forcing users to look at
certificates, we've already failed.  So this means that we should
automate as much as possible.  This begs the next question: which of
these risks are realistic enough that we want to block access?

If people want to advocate for blocking or warning about every site that
uses an SSC or an expired cert, I think you'll quickly find that users
will either get around the blocking and continue to these sites anyway,
or such sites will all start getting cheap certificates (the $20
analogy).  While the latter would imply that the warnings are working,
it also means that we really haven't done anything, we've just shifted
the problem.  We've forced that class of websites to shell out $20, but
effectively haven't accomplished much more.

This is where we seem to disagree: whether an SSC is as secure as a
low-grade certificate.  There are two main differences: the domain
ownership verification and the ability to do revocation.  So far no one
has made a convincing argument that passing a domain ownership test to
purchase a low-grade certificate is sufficient to prove that a site is
not malicious.  Regarding revocation, if the owner of an SSC has reason
to believe that it's compromised, they can just generate a new one
(whereas the owner of a CA-issued cert would fill out a revocation
request and request a new one).  Sure, a lazy person might not
regenerate the SSC, but then again a lazy person might not fill out the
revocation request either.  I'm also not sure there are any convincing
arguments that the private keys are going to be kept safer in either
scenario either (I'm not talking about the CA root key).

Anyway, this is tangential to my main point, which was we need to be
focusing on what to display to the user.  Before whining about all the
possible risks for every PKI-related scenario, you need to be asking
yourself: What is the likelihood of this threat?  If we cannot automate
the decision (allow/deny) and must display a dialog box to the user,
will grandma be able to make the right decision?

serge

Stephen Farrell wrote:
> 
> Serge,
> 
> While I think we all believe that the presentation of security
> indicators has been done badly over the last decade, I do not
> believe that one can therefore say that the security analysis
> that underlies current implementations is wrong.
> 
> I also don't find a scattergun set of arguments to the effect
> that "PKI is not perfect, let's throw up our hands" are at all
> convincing.
> 
> In particular -
> 
> - "No information available" is IMO overwhelmingly more likely
>   than finding a CRL or getting any OCSP response, and ignoring
>   this is not an option for anyone who cares about revocation
> - Beginning an argument with a "what about $20 certs" but
>   following up with "let's ignore the $$" seems to me like a
>   bad way to argue - your argument is either about low assurance
>   or it isn't
> - Saying that anything at all "require(s) little vetting by a CA"
>   shows a misunderstanding of PKI, where CAs are not required
>   to do anything, but instead declare via CP/CPS what it is that
>   they claim to do (exceptions to this are connected to legally
>   significant signatures, which are very rare and probably out
>   of scope of this WG and certainly unrelated to TLS); while you
>   may disagree with aspects of how PKI is defined/operated it is
>   not ok to ignore those definitions/operational aspects
> 
> Basically, I think you need to make a *much* better constructed
> argument, that needs to be demonstrably well-informed about the
> details of PKI, if you are going to be convincing in terms of
> the presentation of revoked certs or SSCs.
> 
> Stephen.

-- 
/*
Serge Egelman

PhD Candidate
Vice President for External Affairs, Graduate Student Assembly
Carnegie Mellon University

Legislative Concerns Chair
National Association of Graduate-Professional Students
*/

Received on Monday, 9 July 2007 22:59:11 UTC