httpsy, SSH and eternal resource locator/WAX (Re: Announcing httpsy://, a YURL scheme)

[Adam Back]

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 majordomo at metzdowd.com

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com