[tahoe-dev] simple authority taxonomy versus a kind of privacy

[Zooko Wilcox-O'Hearn]

Dear Brian and tahoe-dev:

I was wondering about the word "traversal cap", thinking "Isn't that
what one might call a 'deep verify cap'?".  Then I thought "Hey wait a
second, all of our directory caps are deep.".  (I'm glad about this fact
-- I think that all directory access rights being transitive is simpler
than having both transitive and non-transitive, while being expressive
enough for our needs.)

Then I thought "Hm, so why don't we just make Directory Verify Caps
deep?".  The answer has to do with privacy in the sense of
traffic-analysis-resistance, but I don't think it is a win.  More on
that below.

Here is a set of four figures which I hope illustrate why I hold a high
value for having few types of capabilities and having their meanings be
mutually orthogonal and consistent: for *conceptual simplicity*.

immutable files:
                 Read Cap        Verify Cap

mutable files:
Write Cap       Read Cap        Verify Cap

directories:
Deep Write Cap  Deep Read Cap   Verify Cap

Figure 1: taxonomy of capabilities in TahoeLAFS v1.5


If we added traversal cap to directories, it would become:

immutable files:
                 Read Cap                        Verify Cap

mutable files:
Write Cap       Read Cap                        Verify Cap

directories:
Deep Write Cap  Deep Read Cap   Traversal Cap   Verify Cap

Figure 2: taxonomy of capabilities with Traversal Cap

("Traversal Cap" in this figure could also be named "Deep Verify Cap".)


If instead we changed directory verify caps to always be deep, then it
would be:

immutable files:
                 Read Cap        Verify Cap

mutable files:
Write Cap       Read Cap        Verify Cap

directories:
Deep Write Cap  Deep Read Cap   Deep Verify Cap

Figure 3: taxonomy of capabilities with all dir caps deep


If we were then to add immutable directories (ticket #607), then it
would become:

immutable files:
                 Read Cap        Verify Cap

mutable files:
Write Cap       Read Cap        Verify Cap

immutable directories:
                 Deep Read Cap   Deep Verify Cap

mutable directories:
Deep Write Cap  Deep Read Cap   Deep Verify Cap

Figure 4: taxonomy of capabilities with immutable dirs


To me, Figures 3 and 4 are conceptually simpler than Figures 1 (the
current situation) or 2.

Now the reason why it could be useful to have a Shallow Verify Cap -- to
give someone the ability to verify the integrity of a directory without
also giving them the ability to get the verify-caps of the children --
is for a kind of data-privacy.  You might want to give lots of people
the ability to verify the integrity of your directories without also
giving them the ability to trace your directory structure -- the sizes
and link structure of your directories and files.  As we've recently
been discussing, it might be nice for every storage server to have a
verify cap to go with every share that it holds.  We generally agree
that "verify caps are not secret" -- everyone in the world can see
everyone else's verify caps.  You might not want everyone to be able to
see the shape of your filesystem though!

The only problem is: *they can do that anyway*.  Anybody who can observe
your Tahoe storage service connections (even though they are encrypted)
or who operates a storage server can easily detect the exact structure
of your filesystem -- which directories are linked to which other
directories and files, as well as the precise size of all of the files.
To defend against this sort of traffic analysis or pattern detection is
somewhere between "hard" and "impossible".  Our comrades over at the
GNUnet project, the Freenet project, and others have been trying to
develop such techniques for years (both Brian and I have contributed to
such projects in the past, Brian more recently than I).  Whether they're
close to succeeding is not clear to me (perhaps some representative of
such projects or someone whose expertise is more current than mine could
speak up).  But it is certain that TahoeLAFS will not offer such privacy
in the next couple of releases.

So on the one hand, I don't want to mush together the ability to
shallow-verify and ability to deep-verify and thus preclude a user from
exposing one without the other.  That's why we call it "The
Least-Authority Filesystem": because we believe that each authority that
you can grant ought to be the least authority that you might want to
grant.  But on the other hand, the reason we call it "Least Authority"
instead of the older term "Least Privilege" is because we recognize that
the de facto ability to accomplish a goal ("authority") is what is
important, not whether you have nominally been granted the official
"privilege".  That is: people already have the authority to deep-trace
the structure of your filesystem, whether or not you officially grant
them a capability to do so.

There is another maxim in the capability security community (I believe
it may be due to Chip Morningstar): "Never prohibit what you can't
prevent.".  In fact, offering separate Shallow Verify and Deep Verify
Caps could endanger people instead of helping them.  Imagine that you
read the docs for TahoeLAFS and learn the difference between shallow-
and deep- directory verify caps.  Now you go out to use Tahoe or write
code that uses Tahoe, and you have the idea that by choosing not to
expose the deep ones you are safe from people learning about your
filesystem structure.  Your belief is misguided, and if you rely on your
filesystem structure being private, you may suffer ill.

My final argument is that we shouldn't pay a cost in conceptual
complexity today for a potential future feature, if we can instead
implement that feature when we later come to need it.  If shallow verify
caps will be useful in the future, when TahoeLAFS has grown an
anonymity/privacy feature (or married a project such as GNUnet or Tor
which already has one), then we can at that time implement shallow
verify caps, guided by our enhanced understanding of the threat model
and the defenses we will then employ.

Regards,

Zooko

tickets mentioned in this message:
http://allmydata.org/trac/tahoe/ticket/607 # DIR2:CHK

tickets not mentioned in this message:
http://allmydata.org/trac/tahoe/ticket/217 # DSA-based mutable files --
small URLs, fast file creation
(Search in text for "shallow read-only caps".)