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

And so we can go round this loop again. You propose to "fix" this problem by removing all meaning from the URL. How do I then find out what the URL is good for?—Ben

Great question. It is clarifying to think about this problem in a world where URLs truly have all meaning removed from them (I would claim that URLs don’t have any meaning to remove already, but that is a matter that takes us away from engineering and into philosophy, so let’s not go there :-)

Suppose all URLs were large random strings. It is then obvious that meaning must be imposed externally (as opposed to the current situation where meaning still has to be imposed externally, but it is not obvious :-).

Now we use the usual capability tenet, only connectivity begets connectivity. A friend whom I trust to supply a first crucial URL gives me a URL to a site he calls "Goggle", and says it’s a great place go to find other sites that other people will recognize. He gives the URL to me either by handing it to me physically on his flash drive, or he emails it to me, or he reads it off to me over the phone (carefully, though we make the string long enough, it would be really hard for a spoofer to figure out a URL that was similar enough so that a person could make a mistake and be likely to wind up at the spoof site, i.e, an error will take you to nowhere, so you can try again :-).

Now I have a site that my friend Bob trusts as a place to find other sites, I give it the pet name Bob’s Goggle. I type in "paypal", and go to the first hit and the default name suggested as a pet is bob’s goggle’s paypal.

Meanwhile, I also ask alice for her favorite search site. She’s got one she calls Google, which she sends me. If this is the same site as bob’s goggle, my user interface notes that, and I have new confidence in Goggle. Perhaps it is different, and I change the name to Gargle so that it is sufficiently different from Goggle so I don’t get confused. I search for paypal on that one too, and take the first hit, which perhaps is a match for the first hit off goggle. Cool. Looks like, by signing up with this paypal, I will be on a system that allows me to exchange bucks with both alice and Bob.—marcs

I’m new to all this, so maybe I’m thinking about things the wrong way, but my first impression is that your conclusion above looks like a bit of a leap. It looks to me like it is succumbing to two fallacies about reasoning about trust: 1) "transitive trust"; 2) the difference between "I trust X" vs "I trust X for purpose P".

You assumed that if Alice trusts Goggle as a useful general-purpose search engine and if I trust Alice to introduce me to useful general-purpose search engines, then Goggle can be trusted to introduce me to trustworthy payment systems. But that is questionable. With longer and longer chains, it becomes more and more questionable.

Also, you assumed that if Alice introduces me to Goggle as a useful general-purpose search engine, then she would also be willing to claim that the first search result for the search query "Paypal" is trustworthy for purposes of handling your money. But maybe Alice only intended to assert that Goggle is adequate for the former purpose but not for the latter.

I’m not convinced it is as easy as all this. This strikes me as a problem that might be unavoidably hard. What seems to make it hard is that it involves humans. We’re trying to solve a people problem with an (admittedly elegant) mathematical technique. That strategy worries me, because technical "solutions" to social problems often don’t work nearly as well as one might wish. The human is embedded in the protocol, and we’re trying to prevent social engineering attacks on the human, which means that we have to anticipate all the ways that humans might be fooled into coming to the wrong conclusions—but humans behave in surprising ways, and their behavior isn’t easily formalized in a mathematical framework.

To put it another way, maybe this isn’t one of those problems with a perfect and elegant principled solution. It might be an engineering problem where no single clean solution suffices, and where workable solutions tend to look messy. I don’t have any proof of that, just a fear that it might be the case. But we shouldn’t let my fears stop us from looking hard for good solutions to this problem, so please don’t let these remarks get in the way of the continuing the discussion.—David

I believe all we’re trying to do and in fact all we can do is to enhance the safety of communication like:

"<I> (who you have some trust in) assert <this> about this other <entity>"

If by technical means we can enhance the safety of the knowledge of <I> and <entity> and the communication about any such assertion, <this>, then I believe we’ve enhanced human communication—whatever else one might say about the foibles of such communication. This seems to me a worthy cause—made somewhat more tractable in the digital realm.—Jed

How do you determine that the ’site’ is the same? Do you do a URL or DNS or IP match? It seems to me you leave yourself vulnerable to IP or DNS spoofing or even just being on another network. You also have the possibility of missing the identity of one URL you receive uses a DNS and another an IP or a DNS alias or ...

It seems to me what you want to do the identity match on is something like a key fingerprint. If you treat the address portion of the URL as really just a hint of how to reach the intended destination but demand a public key fingerprint match to determine the identity then it seems to me you have a pretty strong system.

One interesting aspect of this thinking for me is that in most of my past capability thinking I’ve focused on the concerns of assuring the server that a client is presenting a valid capability. I haven’t focused on the concern of the client that it’s communicating with the appropriate server—also a valid concern.—Jed