[cap-talk] Firefox and identifiability, small steps or large

[Ian G]

Ka-Ping Yee wrote:

>Right.  I'm sorry; i should have stated what i meant more clearly.
>Yes, the user can choose whether or not to trust the CA, and can
>decide to trust "non-standard" CAs if he or she wants to.
>
>However, my understanding of the paper is that the trust indicator
>is based on the site certificate.  That means the user doesn't
>really get the choice: the *site* gets to choose the CA under
>which to present its certificate.  So it is entirely likely that
>the user will want to establish (or already have) a trust relationship
>with the site (e.g. his bank), but not have a trust relationship with
>the CA.
>  
>

Certainly the site gets to choose who signs its
certificate, and the SSL/PKI admits no multiple
signing.

Further, once the cert is presented, this becomes
the trust index.  That is, the key is cached and the
key becomes the index for any trust calculations.
(The cert is irrelevant to the caching arrangement.)

>To make this concrete, suppose that Alice doesn't trust VeriSign
>because she knows that they have been screwing over the Internet
>for their own selfish purposes.  But Alice wants to do business
>with Paypal.  https://paypal.com/ presents a certificate signed
>by VeriSign.  So if she wants to communicate securely with Paypal,
>she is forced to trust VeriSign in order to do so.
>  
>

1. Um.  I have to think about this.  Once she has
chosen the certificate, that key is set.  Now,
assuming that the key is good on day 0, even
if VeriSign go and do a fraudulent cert, it
would still be a different key - as the browser
+ user have got their logo system indexed to
each key (which happens to be wrapped in a
cert).

An attack would cause notice that a new Verisign
cert had been issued, and there was no petname
or logo or other history.  There is the Verisign
logo shown, though, which is reflection that
Verisign are doing the attack.

Now, I know this isn't much of a defence, but
I believe it to be enough to force VeriSign to
behave, as their brand would now be on the
line - in the user's face, as it were.  For various
reasons I think that would be a big improvement
over the situation we have now, where any
such attack by *any* CA goes through unnoticed.

2. Alice doesn't have a right to access any given
site on her terms.  And as a security exercise,
I'd think we should be careful not to get caught
up in politics or commerciality, except where
we hit brick walls.

>For Alice to be placed regularly or frequently in the position of
>having to rely on CAs that she doesn't know or doesn't trust is
>dangerous.  If she is forced to do this often enough, she may
>learn to ignore the CA logo.
>  
>

Once Alice is given the decision, I'd say it is
up to market forces - including her big mouth -
to decide what happens next.  If Alice is upset
enough she either shouts out or changes to
another site.

In terms of learning to ignore the logo:

I think the security equation is better for the
logo of the CA being there than not.  If she
then learns to ignore the logo, and then she
is phished, because the logo changed ... well,
the browser did its best.

This is a bit like putting seat belts in cars.  Yes,
the driver can undo them.  Can we go one step
further by forcing Alice to buckle up with police
and mechanical restraints?  Debatable, and it
may reduce security.  We are then at the point
where we should leave that experiment to later,
perhaps.

OTOH, there is no cost if she ignores the logo
and nothing happens.  So some people will
be better off, and this makes for a definite
improvement (hopefully pareto, if you know
what I mean by that).



>>So in security terms, this is the SSH model,
>>where the problem is divided and conquered.
>>    
>>
>
>It's not quite the same because of the addition of the CA, a CA
>possibly unknown to the user.
>  
>

OK, yes it is not quite the same.  Here's where
we are at:  the CA model is embedded into the
browser, but the CA spoofing protection is
being bypassed.  In order to use the spoofing
protection, we have to force the traffic over to
cryptographic traffic, and we have to clearly
present the identity of the cert, which is the
available index element.

Hence the heave emphasis on high quantity
and quality graphical stuff to create a big visual
signal of SSL and cert usage.

But, once we've done that, it isn't the cert that
is protecting the user, rather it is the key.
That's why I say SSH model.  Now, the cert is
still there, and the CA sig component is
available as additional info which can be used.

Combined, we can use the CA for certain high
value targets.  For example, consider VeriSign-
Gold which costs $100,000 and there are only
100 of them.  It gets a gold coloured logo, and
the user is taught that this is ... well, golden.

Now, if our phisher manages to pull off some
other tricks like fiddling with petnames or the
logos or what have you, and he picks up a cheap
dodgy NoName cert, he still has to contend with
the fact that Alice expects to see the Gold logo,
as well as her pet names and logos (which have
been turned off by some trickery).

It's just one more barrier to cross.

Also notice how this approach - by opening up
the market for valuable certs - covers the IDN
Shmoo attack.  At least, Paypal can afford to
be in the golden circle where Verisign guaruntee
to check each application carefully.

iang

-- 
News and views on what matters in finance+crypto:
        http://financialcryptography.com/