\section{Trust Networks}
\label{sec:design-trust}

\footnote{This section was written in part by Brian Sniffen.}
This system is built off some amount of trust in the other nodes of
the servnet.  In particular, the protocol supports some enforcement of
good practice by the other nodes, but there is still plenty of
opportunity for nodes to obey the rules until they are sufficiently
trusted, and then start breaking the rules in subtle ways. For
instance, a node might sometimes fail to provide a receipt to a
share's buddy during a trade, introducing confusion as to whether the
other side is trying to trick the buddy into believing that the share
had been traded away. More destructive would be for a node to never
query the buddy shares for any of the shares it possesses, or even
wrongly accuse a different node of losing that share. The list goes on
and on. However, with careful trust management, each node ought to be
able to keep track of which nodes it trusts; with the cushioning
provided by Rabin's information dispersal algorithm, only a
significant fraction of the nodes turning evil at once will result in
actual loss of files.

\subsection{Protocols for informing neighbors}
Each node needs to keep two values describing each other node it knows
about: trust and metatrust.  The first, trust, signifies a belief that
the node in question will obey the dictates of the Free Haven
Protocol.  The second, metatrust, signifies a belief that the
utterances of that node are valuable information.  For each of these
two values, each node also needs to maintain a confidence rating.
This serves to represent the ``stiffness'' of the trust value.  For
example, a node which has Trust 100 but Confidence 1 will be trusted
with a great deal of data, but will lose or gain trust rapidly in
response to the utterances of other nodes.  Exactly how these values
are used is left entirely up to each node.

Some nodes may wish to set all meta-trusts to zero, thus ignoring all
outside utterances.  Other nodes may wish to set confidence values
very high, ignoring not only outside utterances but also direct
evidence of wrongdoing.

Nodes should broadcast referrals in several circumstances:
\begin{itemize}
\item When they log the honest completion of a trade.
\item When they fail to verify that a buddy of a share they hold is safely held.
\item When the trust or metatrust in a node otherwise changes substantially.
\end{itemize}

\subsection{Getting information}
In addition to referrals, the trust system should gain information
from the operation of its own node.  Such information must be treated
as having a very high metatrust --- as we're talking to ourselves, why
would we lie?

The trust system should log all transactions between its own node and
others.  It needs this information to determine both when shares have
successfully expired and when shares have been deleted before their
expiration date.  

\subsection{Introducing new nodes}
One of the most important parts of the design of Free Haven is the
capacity to seamlessly integrate new servers. These servers need to be
able to join and participate in the servnet simply by installing some
simple packages and making contact with public servnet nodes.  Such
nodes (e.g. \texttt{freehaven.org} itself) have the option to
configure themselves as \emph{introducers}.  While nodes configured
with the default settings should ignore communications from unknown
nodes, introducers respond to such communications by querying the new
node for its public key and return address. (Presumably this is
some sort of anonymous communications channel, such as a Mixnet.)

Provided with this data, the introducer adds the new node to its
database, then broadcasts a referral of that node.  Other nodes are
welcome to do what they like with this information.  It is suggested
that the initial trust and metatrust values both be zero, with some
small amount of confidence in each.  The introducer may also wish to
send to the new node a referral for each node it knows about, thus
assisting in keeping the network as fully connected as possible.

From this point, it is expected that existing nodes will attempt to
offer trades to the new node, and vice versa.  

\subsection{Purging old nodes}
\label{subsec:node-exp}

Over the course of the operation of Free Haven, many nodes will arrive and
many nodes will depart. However, due to the nature of the communications
channel we have chosen, there is no way of knowing if a message does
not arrive at its destination through the mixnet. Because of this lack
of bounces, there is no direct way to determine if a remailer address
is no longer in service.

To maintain a set of active servnet nodes, we simply keep track of
the number of recent trade requests to a given node which were not
answered. After a certain threshold of unanswered trade requests, we mark
that node in the node database as `dormant'. This means that the node is
not currently responding to trade requests, and so we should neglect to
include that node in our broadcast messages as well.  This modification
is implemented in the Communications module by simply skipping over
dormant nodes during a broadcast. In addition, the trust module should
skip over dormant nodes when choosing appropriate nodes for trades.

If a trade request or broadcast arrives from a dormant node, then we
can conclude that the node is not actually dormant and resume sending
broadcasts and offering trades to this node.

There may be a number of attacks based on the fact that servers might
stop sending broadcasts to a silent node. However, it seems that the only
way to prevent a node from responding is to either control that node or
control an appropriate edge in the mixnet. For an adversary with this
level of power over the system, a more thorough denial of service attack
would instead be possible.

%Old nodes need to be removed from use after a while, since continued
%mail bombardment from the mixnet to a closed account will eventually slow
%down the service (as well as anger a lot of systems administrators). 
%On the other hand, any operation which can remove nodes from the servnet
%must be handled very carefully, because it's easy to introduce security
%vulnerabilities that let an adversary disable a node.
%
%One solution is to allow the trust network to gradually lose trust in a
%given node to the point that it doesn't ever send trade requests to it.
%On the other hand, broadcast requests will still go to it. This means that
%we might consider a sort of `ping' query for a node, to make sure that
%it is still responding to its mail. On the other hand, this introduces new
%denial of service attacks where a node might answer pings but not other
%queries.  
%
%Therefore, we have chosen to add a new behavior to the trust system.  As
%the trust database logs all transactions, it is in a position to
%notice when a multistage transaction fails to complete.  In cases
%where such a transaction fails to complete, the trust system should
%notice and mark that host as ``potentially dead.''  After a
%potentially dead host continues to ignore queries for some time, it
%should be marked ``presumably dead.''  A host should be removed from
%the ``dead'' lists as soon as it reopens communications.

\subsection{When to trade}
While individual node administrators should be free to change this as
they wish, the default Free Haven installation should base its unit of
trust currency on the product of share size and storage duration:
megabyte-months.  Each host should also grant a small amount of
leeway.  This allows new nodes, for example, to be able to trade small
shares despite their 0-trust rating.  

A reasonable policy will balance trust-increasing trades with
low-confidence nodes against guaranteed-safe trades with high-trust,
high-confidence nodes.

\input ./fh-impl-trust.tex