Nathan Eisenberg wrote: > I might be confused now. Isn't this what aliases are good for? For > example, > > http://216.243.10.44/atlas/atlas_networks_logo_143x75.png is an alias of > URI:CHK:tslxqfx375xr7dvehtuytz37u4:j2ygje3wlaf3vw6wustqnfzdl2qy23kbojhxpfkxcp74wh5ac7jq:3:10:5433
Nope. If I tell you to use your personal Tahoe agent and fetch URI:CHK:tslxq... (from a given grid), then either you will see the Atlas Networks logo, or your agent will signal an error that it was unable to fetch the requested file. The set of people who are able to control which logo you see are: * you * the person who has control over your Tahoe agent: the root admin on your machine, the author of the Tahoe code, your OS kernel, etc.. these are traditionally known as your "TCB" * the person who created that filecap Nominally, I (as the person who told you to fetch URI:CHK:tslxq.. as opposed to some other filecap) get to control what you see too, but a property of immutable files is that they map to exactly one sequence of bytes, so they have the extra guarantee that two people who fetch the same filecap will see the same thing. These guarantees are backed by the usual cryptographic assumptions: nobody's broken AES or SHA-256 yet, and you consider numbers like 2^-128 to be effectively zero. Whereas if I tell you to use your web browser to look at http://216.243.10.44/atlas/atlas_networks_log_143x75.png , the set of people who are able to control what you see are: * you * the person who has control over your web browser, and your TCB * the dozen-or-so routers who sit between you and 216.243.10.44, anyone who's broken into them, including the coffee-shop wireless network owner and the person who guessed the default password on their cheap linksys wifi box, or the bad guy person who's running the wireless network named "Free Public WiFi" that your computer decided to use because it had the strongest signal-to-noise ratio * the thousands of routers capable of injecting BGP entries that will direct 216.243.10/24 traffic to the subnet of their choice * the person who has control over the web server and proxy table on 216.243.10.44 * the person who has control over the Tahoe agent on 216.243.10.44, and its TCB * the person who created the filecap referenced by the proxy table If that server were offering TLS/SSL and I gave you an https URL, then the reliance set would turn into: * you * the person who has control over your web browser, and your TCB * (the owners of any of the hundred-or-so private CA keys that your browser has embedded inside it, or anyone who's managed to steal them, or anyone who's used the recent MD5/TLS bugs to forge a certificate) intersected with anyone who can control where your traffic goes * the person who has control over the web server and proxy table on 216.243.10.44 * the person who has control over the Tahoe agent on 216.243.10.44, and its TCB * the person who created the filecap referenced by the proxy table And if I'd given you a DNS name instead of an IP address, we'd have to add: * any of the half-dozen-or-so DNS servers involved in the translation process * anyone who can poison the DNS cache in your machine or one of those other servers Our goal is to provide better guarantees than the usual URLs. Tahoe's filecaps provide very strong promises, but only if you use them directly (through a Tahoe client/agent/gateway node on your own computer). Anything that maps a different string (without the long cryptographic goo) to a filecap+agent will lose some of the strength of those promises. Even Zooko's desired URL (http://testgrid.allmydata.org/..FILECAP) must add several parties: all of the ones I listed above, including the DNS servers. However, since you (as a Tahoe user) can recognize that URI:DIR2-RO:j74uh.. piece as a tahoe dircap, you could cut-and-paste it directly into the Tahoe node of your choice, and get all the good security promises we want without relying upon any of those other parties. Expressing the dircap in an HTTP URL like this is a compromise: non-Tahoe users can get insecure access to the intended data, while knowledgeable Tahoe users can get secure access to it. (Some day, we'll have tahoe-specific URLs like tahoe:DIR2-RO/j74uh.. and all web browsers will know how to handle them with their built-in tahoe plugins, and we won't have to compromise anymore). Hopefully I understood your objection.. if not, please feel free to correct me! Also note that "alias" as used by the Tahoe CLI (as in "tahoe ls alias:") does not give up these guarantees: that alias maps through a trusted channel (i.e. ~/.tahoe/private/aliases) to a dircap. Using these CLI aliases does not add any new parties to your reliance set. cheers, -Brian _______________________________________________ tahoe-dev mailing list [email protected] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
