[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: Draft: Directory agreement in Type III

On Wed, 20 Aug 2003 15:35:39 -0400, Nick Mathewson <nickm@freehaven.net> wrote:


[lines wrapped]

hmm, that's the way Opera works (the M2 client), I hope it is not too inconvenient, I also don't know how to sign messages with pgp using M2, I will be switching back to netscape 4.8 some day but not now because I will be moving homes shortly (few weeks at most I hope)...


On Wed, 2003-08-20 at 14:03, Thomas J. Boschloo wrote:

On Thu, 14 Aug 2003 13:22:21 -0400, Nick Mathewson <nickm@freehaven.net> wrote:

[...]

> - When the protocol succeeds, it should create a directory
> signed by a large quorum of directory servers.  If at least
> half of the quorum has signed a directory, clients should be
> able to trust that directory.

(oops, this should be "greater than half".)

See Steve's point. This seems rather arbitrary to me. Why only half and
not e.g. 75%? Why not 80%?

"Greater than half" guarantees that if there are multiple competing
fragments of a quorum signing different directories, no more than one of
those fragments will be trusted by the clients.

Or zero if two do not list it and the rest is divided equally. I had this thought today (there I go again..), why not take the biggest fragment of directory servers and use them as somewhat stats? mixes with 100% would be listed on top and mixes with 0% on the bottom, but they would still be listed. Or does this break anonimity? It would be a bit like MINREL in mixmaster..


This seems also to cause more problems than it solves IMO. Honest means
that a mix tries to be reliable -> which it can't guaranty depending
on his ISP; it does not attack the network -> which at least cannot be
proved (or disproved) in the current mixmaster network; and it doesn't
break users' anonimity.

If this credibility becomes automated in clients, I forsee lots of
trouble in arriving at a single directory each day. Every directory
server admin will have it's own set of 'credible' and 'honest' mixes.
It might even not be the fault of a certain mix that it loses mail.
The fault might also be on the receiving or even sending side which
might lead to a lot of finger pointing and unhealty discussions (high
bloodpressure kind of discussions).

(Note: Reliability is not the same as honesty -- you might want to read
the document again.  A mix is 'reliable' if it obeys the protocol and
relays messages correctly.  A mix is 'honest' if it isn't trying to
break people's anonymity.  A mix is 'credible' to you if you guess it's
honest.)

Ah, it says "by correctly processig and delivering" and I took that for an SMTP/POP3/IMAP5 kind of statement, since that seems to be where things are mainly going wrong in mixmaster.. For credible there does not seem to be a definition in the document. But I am not clear on voting either so maybe I should reread the whole lot. I kind of dismissed voting on a remailers ?honesty? because it seems such a touchy subject (especially since people who run nodes are kind of touchy on the subject of credibility anyway).


If less than half of the voting quorum directory servers
think you're credible, you're not credible.  If more than half think
you're credible, you're credible.  If the quorum makes bad choices,
you're always free to get some likeminded friends, start your own, and
convince people to trust you instead.

That would grow the network, which is probably always a good thing! Point taken.


(Note: If you can DoS half of the servers on any mix network, and people
use message paths of any appreciable length, you can already keep the
system from running.)

That is true, let's just hope that does not happen. Why not use hashcash to avoid flooding attacks? Like no hashcash -> message discarded from inbox pool at sight! Since the keys change on a daily bases it might just work.


The issues here are similar to some examined in http://freehaven.net/doc/casc-rep/casc-rep.pdf
http://freehaven.net/doc/mix-acc/mix-acc.pdf

Any working solution to them would be much appreciated, from any
quarter.

I will DL them, hope they are not too lenghty ;-)

High regards,
Thomas
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/