Recently, the Shmoo Group discovered that Firefox is vulnerable to precisely the exploit that i predicted in my 2002 paper—Ping

➡

The central point of my essay on the petname toolbar is that phishing is the result of name conflation.—Tyler

➡

So how, in this system, does the user come to trust Paypal (as opposed to someone pretending to be Paypal)?—Ben

➡

If I’m understanding the discussion so far, I think the answer is that the issue of trust is separate from the issue of identity.—Jed

➡

Indeed, but I am no closer to understanding how the user ever gets to a state where they can do anything useful.—Ben

➡

I gave some examples in my next message on this topic. Perhaps you could address them.—Jed

➡

I agree it solves the problem of confusable URLs.—Ben

➡

What don’t you believe is practical?—Jed

➡

Let’s say I start with actually visiting my bank, and getting the fingerprint of their cert. I then tediously type that into my machine.—Ben

➡

Forget the tedious typing. You give them your smart card (or something like) and they add a Petname binding to it. You bring it home and plug it into your system with your browser running and the binding is uploaded. Or if you have secure access to their Web site you can pull down the binding from there.—Jed

I’m sorry to be such a curmudgeon here, but-- this doesn’t sound like a solution I can get terribly excited about. First, this requires absolute trust in "them". "them" can add malicious Petname bindings without limit. So from a security point of view, what this accomplishes is nothing to jump up and down about.

Second, the useability factors here are lousy. You mean I can’t learn about new sites by word of mouth? Gee, that sucks.

Maybe this is the best we can do and still remain secure. Could be. But if so, this is cause for lament that we can’t solve people’s problems better (not cause for pride in the elegance of our abstractions).

Sorry to be so negative.—David

This isn’t a petname. At least as far as I know a petname must be chosen and set by the owner. If it is suggested by some other agency, it is a nickname. Now, if your model is that they give you a nickname and you then elect that as a petname, that would be ok.

(This might sound picky ... but the concept of petname is quite rigourous in that it is between the user’s mind and their agent. If that changes, then *all* security bets are off, I suspect, and we have to go back to the drawing board.)—Ian

Also note that the system may display a suggested nickname, but the user has to type it in again if that’s the pet name they want. If the nickname is put into the pet name field by default, then we have the same kind of similar character spoofing issues that started this thread.—David

In what I hope is positive criticism I do believe there is a fair amount of what I feel is counterproductive ’pickyness’ going on generally in this discussion. I’m hopeful that we can separate out the basic mechanisms available from implementation details.

<As I noted elsewhere in a later message> of course the Petnames are managed by the user. The interface could look something like:

"Bank of America suggests the binding of the name ’Paypal’ with the URL <paypal.com> and the certificate fingerprint: A9:04:4D:C2:74:5E:05:D9:28:44:E0:8C:53:E2:31:9A

The ’Paypal’ Petname is available. Would you like to assign this name as above?"

It’s your software presumably trusted with the right to make Petname bindings. It has access to the information from your bank (perhaps even binding some of its identification to its local Petname...) from the card or perhaps from a previously known Web site. It presents that information to you and lets you choose the Petname binding if you like.

OK, now before anybody gets carried away criticizing yet more details of that implementation, please first try to think about whether the criticism is about the implementation or the basic mechanisms. If the implementation, perhaps you can suggest a better implementation. Maybe one that’s more user friendly or perhaps one that overcomes some flaw apparent in the above. I don’t care too much about that aspect of things. I believe such things will work out over time.

What I really want to hear are criticisms that suggest fundamental flaws in the available mechanisms/tools. For example, I feel that merging of the URL with the SSL certificate fingerprint adds security to the Petname binding. I’d be interested to hear criticism of that underlying mechanism.—Jed

Ah, this is more akin to an introduction. —Ian

Fine—call it what you like. I’ll try to adopt any agreed upon language. From my perspective the fundamental nut of the mechanism is the ability to communicate some trust from one trusted entity to another, in the case under consideration where they both speak digital. And of course the communication is to a user at a browser ultimately using a Petname or Petlogo. I believe the "tedious typing" criticisms are bogus as I feel they apply only to the interface between analog and digital.

The thread of getting here from "Firefox breaks the principle of identifiability" seems a rather long and torturous one, but I believe I can still follow the pieces that led us here.—Jed

Right. There are three components here:

1. the Introduction, which arives from someone you trust, 2. the addition of this pointer to your name database, and the selection of your pet name, and 3. an arrival of some more trust-adding information on some pointer you already have.

Now, as a basic mechanism that sounds fine. I also think the typing part is something that will be finessed once the basic structure is laid out. I.e., parts 1,3 fall out in the wash.

However, I suspect none of this reaches the realms of practicality until it is decided what the basic unit of trust is going to be in the browser. Right now it might be an x.509 key. Other proposals have been made. Unfortunately, we can’t see enough into the future to be able to decide how that is going to play out, so until we do know, John Halleck’s criticism rules, IMHO.—Ian

Why does this concern you? Go ahead and use an x.509 key now and adjust to something else later if it comes along. Where’s the problem?—Jed

Well, the issue is that "how the petname gets added in and used" is somewhat or highly dependent on how the naming or pointing is done. In software engineering terms, first we would decide on what we are doing w.r.t. Zooko’s triangle, and later on we would fill out the gaps with (potentially) petnames. Mark Miller makes the point that petnames is a device to bug fix the ZT law. First comes the ramifications of that, and later on comes petnames.

Yet, I gather the petname concept is not intending to use x.509 certs. Which means there is a whole naming infrastructure to create and put in place. That looks like a pretty tall order to me.—Ian

You seem to be able to see far enough to see value in the name/identity binding that the Petname mechanism adds. You seem to see far enough ahead to see value in the "YURL" (fingerprint or the like) addition to a URL to get a positive ID to bind with the Petname. Isn’t that enough to move forward? Why wallow in the ambiguous and clearly error prone present when we can see technical improvements—if we can get a consensus...—Jed

Which criticism was that? Perhaps this one?:

Halleck: "It is a nice discussion, but baring smarter users, I think it is theoretical..."

I don’t see anything limiting the Petname mechanism and what is essentially the YURL mechanism to the ’theoretical’ in the absence of smarter users. Both seem to me to add value for smart or not smart (perhaps kinder would be experienced or inexperienced) users.—Jed