I'm not that familiar with SFS, but httpsy sounds quite related to Anderson, Matyas and Peticolas' "eternal resource locator" [1], and the WAX system they describe in that paper. This scheme allows a referer to embody in a URL they refer to authentciation information about the contents of the text in the body of the page referred to (either by SHA1 document hash, or by reference to a signing key the publisher of the referred page may use to sign and update that page's contents). (WAX was also implemented in browsers if I remember from earlier reading of that paper).
Their approach is more directly worried about the risks in pointing at random stuff on the web, and have it change under you. For example I had a pointer to a python implementation of hashcash, and the domain of the author's ISP got sold and now it's a porn site, so where people were expecting some python library code they would have got bounced to some porn site. They were also worried about referring to specific vetted instances of a _version_ of a web page. (The application was refereed web pages with medical reference information). httpsy seems to content itself doing something similar but based solely on the identity (akin to the signature only variant in WAX) where there is no guarantee about the content of the referred page. >From what I could understand from the httpsy pages it sounds like there is a use case where you get redirected from a book purchase site (eg amazon.com) to a book review site and then back from the reviewer to the book site. And the claimed weakness with SSL is that a rogue book reviewer site could redirect you to a different though also certified site. Additionally the use-case supposes that the attacker had gone to the trouble of getting a cert for a similar domain name (eg amaz0n.com (zero instead of o). httpsy seems to claim that instead of showing you the hash of the sites auth information (which Perry referred to), it will instead give you the option to provide a pet name for that site. (eg you put "BOOK SITE" or "AMAZON" or whatever is mnemonic for you as an individual), then if you get bounced to the wrong place you'll be suprised that amaz0n.com is not listed by your pet name but is instead prompting you to check the hash and supply your pet name. (In a similar way to the way SSH warns you if the host key changes for a site your connecting to again, or if you accidentally connect to a similarly named but SSH supporting site with a host key not already in SSH's known hosts file). So the httpsy proposal is really quite similar to SSH, but with pet names. Also I'm not sure what is special about pet names or introducers. All that will happen to my mind is that people will set up informative but bogus meta-rating sites. (Best bookseller "amaz0n.com" plus the rogue amaz0n.com's auth data hash.) And then again the user will end up giving their credit card to the rogue site. Different to the SSL attack but I'm not sure it's overally cleanly solved this kind of human semantic gap attack, or even necessarily improved the situation over SSL. One thing it does do, which is perhaps good, is avoid the central trusted point. (Imagine if SSH used verisign as a CA. If you became the target of some investigation and verisign (or one of the other 50 odd CA vendors) complied with the LEAs, they could trick someone into SSHing into a honey pot instead of the real host they indended to reach). By using potentially out-of-band (emailed PGP signed host-key or user-key) but sticky (via the known-hosts mechanism) SSH avoids that particular central trust issue and also (which contributes greatly to SSH's success if you ask me) this simplifies setup as you don't need to pay money to verisign et al to setup a host for SSH access. Adam [1] "The eternal resource locator: an alternative means of establishing trust on the World Wide Web", Ross Anderson, Vaclav Matyas, Fabien Petitcolas, 3rd USENIX workshop on electronic commerce Augst 1998 http://www.cl.cam.ac.uk/~fapp2/papers/ec98-erl.pdf On Tue, Jul 15, 2003 at 09:06:02AM -0400, Zooko wrote: > > Tyler should probably reference SFS on his HTTPSY pages. Here's a good paper > focussed specifically on this issue. > > http://citeseer.nj.nec.com/mazieres99separating.html > > Although I haven't looked closely at HTTPSY yet, I'm pretty sure that it > simply applies to the Web the same notion that SFS applies to remote > filesystems. > > It is an excellent idea. > > Regards, > > Zooko > > > --------------------------------------------------------------------- > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
