[tahoe-dev] Bringing Tahoe ideas to HTTP

[Brian Warner]

James A. Donald wrote:
> Nicolas Williams wrote:
>  > > One possible problem: streaming [real-time] content.
> 
> Brian Warner wrote:
>  > Yeah, that's a very different problem space. You need
>  > the low-alacrity stuff from Tahoe, but also you don't
>  > generally know the full contents in advance. So you're
>  > talking about a mutable stream rather than an
>  > immutable file.
> 
> Not mutable, just incomplete.
> 
> Immutable streaming content needs a tiger hash or a
> patricia hash, which can handle the fact that some of
> the stream will be lost in transmission, and that one
> needs to validate the small part of the stream that one
> has already received rather than waiting for the end.

I was assuming a real-time stream, so the goal would be to provide a
filecap before the source had finished generating all the bits. This
would necessarily be a mutable filecap, unless you've got some way of
predicting the future :-).

If instead, you just have a large file that a client wants to fetch one
piece at a time, well, Tahoe's immutable-file merkle trees already
handle the goal of quickly validating a small part of a large byte
sequence. You could use this in a non-real-time stream, in which you
process the entire input stream, produce and publish the filecap, then a
client fetches pieces of that stream at their own pace.


>  > upgrade bundles are produced by a very strict process,
>  > and are rigidly immutable [...] For software upgrades,
>  > it would reduce the attack surface significantly.
> 
> But how does one know which immutable file is the one
> that has been blessed by proper authority?

You're right, I was assuming a pre-existing secure "what to upgrade to"
channel which could send down an integrity-enhanced download URL. To
actually implement such a channel would require further integrity
guarantees over mutable data.

As I understand it, Firefox actually has a fairly complex upgrade path,
because only certain combinations of from-version/to-version are fully
tested by QA. Sometimes moving from e.g. 3.0.0.8 to 3.5.0.3 requires
going through a 3.0.0.8->3.0.0.9->3.5.0.0->3.5.0.2->3.5.0.3 sort of
path. The upgrade channel basically provides instructions to each older
version, telling them which new version they should move to.

The best sort of integrity guarantees I could think of would be a rule
that says "the new version must be signed by my baked-in DSA key and
have a version number that is greater than mine", or maybe just "the
upgrade instructions must be signed by that DSA key". It's probably not
a robust idea to make the rules too strict.

cheers,
 -Brian