Re: [freehaven-dev] a few things

["Michael J. Freedman" <mfreed@MIT.EDU>]

At 11:49 PM 2/20/2000 -0500, you wrote:
>
>When we were talking about introducers, everyone seemed to be including the
>trust framework in the setup.  Like, if you don't trust a node's
>new-node-picking ability, you don't add that node.  I was under the
>impression that, because of how "broadcasts" (heh) and file requests work,
>it's important to know all the nodes that all your known nodes are trading
>with. So if one node says "here's a new node" and starts trading with it,
>everyone else has to at least add it to its db, at least for reference if it
>doesn't trust it enough to trade with it.  Maybe that answers my question,
>but I just wanted to bring it up.

I actually wasn't under this impression.  My understanding was that a node
doesn't declare "here's a new node" unless it is performing introductions,
which is exactly what those messages correspond to.  It wouldn't introduce
that nodes to others unless the it passes the :trust_to_introduce() == true
in the trust_db.  

However, your point brings a question to mind that I am uncertain if we
have answered.  Let's say a server A takes a new node B but has yet to
introduce it to friends (which is what we are doing when a node initially
joins the servnet).  The server performs some trades with the new node B.

In the buddy paradigm, the buddy gets a message that it's counterpart has
moved from A to B.  It can modify the share_db info to reflect B.  Without
really thinking about this, it feels like this is fine even if the buddy's
node (server C on which buddy resides) doesn't know about B.

But --
In the file recover paradigm, server D wants to recover a file.  It
broadcasts to all servers (A, C) that it knows about.  Again, without
thinking much about the problem, it seems like we can do a few things:

1.  A looks up the file, finds a receipt in its db that share went to B,
forwards broadcast to B.  I don't like this:  the share could have gone
through multiple hands' receipts weren't really around for tracing like
this, only for repudiation of "you lost my share" messages; receipts may
expire quickly; etc.  Also, I *know* Roger said he didn't want broadcasts
to be propogated by servnets.

2.  We can rely that information dispersal algorithm is robust.  If we lose
a few files this way, it's okay.   This "solution" is just bad.  It ignores
the problem.  Enough said.

3.  Once A trades with B, it broadcasts B to the servnet, although they
might not yet want to trade with it.  This is what Nathan is talking about,
I think.  I see a few potential problems:  other servers might start
trading with B, we probably don't want to expose the servnet (e.g., all the
persistent IDs and reply blocks) to such a new, untrusted node such as B;
if the trust_db includes something like "do I trust A to introduce nodes,"
A really doesn't want to introduce B without trusted it (somewhat) itself -
here, if we trade with B, we need to introduce.  And some others -- I
really just feel like an introduction carries some sign of respect:  if I
bring a friend to a social occasion and he behaves poorly, it really does
affect my social standing at that party.

I *think* I like this solution.  Disclaimer:  it's late and I'm tired...
4.  Until B reaches a certain level of trust (e.g., trust_to_introduce() ==
true  (???)),  A is actually keeping a copy of everything it sends to B.
Therefore, from A's perspective, initial trades are used really only to
figure out B's trustworthiness.  

Still, as far as some sections of the system see it, this is a valid trade:
 buddy should be updated to B (once A introduced B, it might start dropping
it's copies); we don't really want A to trade this share away to another
server. 

But, when D queries for a file, A can send back copy[share] that it is
storing.  For file recovery, we really don't care about anyting like
primary/secondary copies, etc.   If B has been introduced by this point,
D's just receiving two identical shares, which seems fine (and A should
know as soon as B is introduced, anyway).

Thoughts?  I'm not sure that I haven't overlooked something...


>I'm guessing I could pick up from this: some crypto (David said this would
>be connected to C?), -> more C since I do know some of the fundamentals
>since this MUD I'm on is a very hacked version of a C lib, I'd be up for
>Perl but today it seemed like Roger would be taking care of all the Perl
>himself, and one thing I've been very interested in but haven't found a good
>place to start is the whole concept of network protocols.  

As David wrote in his previous email, we won't be directly implementing our
own crypto in all expectations.  For the majority of situations, this is
just linking in libraries, although probably we want some wrappers so that
all of Roger's modules can call a single API, yet users can link in a
variety of crypto libs (depending on their reqs, export laws, OS, etc.)  

Something that might be very useful to read, if you are shaky about the
basics of PK crypto and digital signatures:  There is a chapter in the
6.046 book (Intro to Algorithms - Cormen, Leiserson, and Rivest) which
you'll probably need to buy for that class anyway.  Also, we use Bruce
Schneier's Applied Cryptography fo 6.857, which explains the protocols
quite well without going in depth into all the number theory.

By network protocols - if you are talking about TCP/IP, we actually aren't
doing that much ourselves on the packet layer.  Roger's links to the comm
module is on the socket layer, and the comm's communication with the mixnet
is on the application layer (or, at least, unless we start getting fancier
with implementing a mixnet (argh!) or other such stuff.)

>Other than that... as for the threat model, I don't really think I'm
>inclusive enough in my thinking (if that makes sense) to be good at coming
>up with the less obvious possibilities, but again correct me if that doesn't
>seem to make sense for creating a threat model.
>

David and I are meeting Thursday evening to discuss 1) mixnets and 2)
threat model.  I'll give you some info later - perhaps you like to hash out
this stuff with us.

Thanks,
--mike

---------------------------------
  Michael J Freedman

Mail:  mfreed@mit.edu
Web:     griffen.mit.edu
Phone:    617.225.9381