[tahoe-dev] [tahoe-lafs] #217: DSA-based mutable files -- small URLs, fast file creation

[Brian Warner]

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