[cap-talk] Firefox and identifiability -> Shmoo and the WWW model

Tyler Close list at waterken.net
Wed Feb 9 02:00:08 EST 2005


On Feb 8, 2005, at 6:30 PM, Jed at Webstart wrote:

> At 09:46 AM 2/8/2005, list at waterken.net wrote:
>
>> On Feb 7, 2005, at 8:43 PM, Ben Laurie wrote:
>> > The Shmoo example does not demonstrate anything about PKI (though it
>> > is true that the particular CA chosen doesn't tell you much about 
>> who
>> > bought the certificate, which would strike me as a fairly effective
>> > prevention of the attack - the CA was, however, chosen for 
>> cheapness,
>> > not usefulness).
>>
>> So you view the Shmoo example [1] as a showcase of the PKI providing
>> effective prevention against a phishing attack?
>
> I hope I won't further muddy the waters by getting in the middle, but
> I think all Ben was saying is that the Shmoo example doesn't deny
> the efficacy of 'PKI'.  I guess I have to use that term carefully 
> because
> it seems in some instances to come with the whole burden of the
> hierarchical signing business.  If you limit the scope to using
> public keys (forget the "infrastructure" of signed certificate, etc.)
> for an SSL handshake then I think even in the Shmoo example
> a binding to the MD5 fingerprint would effectively separate
> Paypal: A9:04:4D:C2:74:5E:05:D9:28:44:E0:8C:53:E2:31:9A from:
> Shmoo: 48:3A:50:BF:CA:98:17:61:62:BF:5A:EE:A4:16:FE:85
>
> Since I thought I was reasoning pretty much along the same lines
> as you Tyler I'd like to clarify any differences.

It's specifically the "infrastructure" part of PKI that I think is the 
problem and that I argue is being attacked by the Shmoo URLs. I think 
the Shmoo hack makes at least a couple arguments against PKI:

1. It is not safe for a human to directly receive a name from a 
potential attacker. Our language makes it too easy for the attacker to 
craft a deceptive name. This is an attack against PKI because the 
purpose of an X.509 certificate is to create a Common Name that may be 
exchanged between mutually suspicious parties.

2. Hiding wildly different trust statements behind a common user 
interface is a bad idea. The Schmoo paypal.com certificate says 
nothing, but is polymorphic with a certificate from Verisign. 
(Interesting that this is a violation of the capability design 
principle: "An object must not be polymorphic with another object that 
provides less authority", but doesn't involve capabilities. Perhaps 
this design principle has wider applicability.) This is an attack 
against the specific PKI used for WWW browsing.

>
>> My interpretation of the Shmoo example, and I suspect their intent, is
>> exactly the opposite.
>
> It doesn't seem to me the Shmoo example so much attacks
> 'PKI' as it does the use of the visible representation of a URL in
> a location window as an identifier to attach trust to.

The purpose of the PKI is to enable this GUI. The Distinguished Name, 
but more commonly just the Common Name, is the intended user interface 
to an X.509 identity. The Shmoo example shows that user validation of 
the Common Name is not safe. The PKI binds authentication information 
to identifiers that are unsafe to exchange. The binding is therefore 
primarily used in unsafe ways, such as in HTTPS WWW browsing.

>
>> If we disagree on this point, we must have wildly
>> different understandings of the use model the WWW presents to users.
>
> I'd be interested to hear what sorts of differences you are imagining.

For example, it appears Ben believes that user viewing and validation 
of the X.509 certificate is part of the browsing workflow. I disagree. 
It appears Ben believes it's OK that it is unsafe to follow a hyperlink 
provided by an untrusted source. I disagree.

> Thanks for your patience in clarifying these issues Tyler.  email is
> a pretty rotten means for communication of this type except that
> it has the practicality advantage of being able to get us all 
> "together"
> - virtually anyway.

My pleasure, this is a 'pet' topic of mine. ;)

Tyler

---
The web-calculus is the union of REST and capability-based security:
http://www.waterken.com/dev/Web/



More information about the cap-talk mailing list