[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[minion-cvs] Move open specification issues into their own document
Update of /home/minion/cvsroot/doc/spec
In directory moria.mit.edu:/tmp/cvs-serv8522/doc/spec
Modified Files:
E2E-spec.txt dir-spec.txt minion-spec.txt
Added Files:
spec-issues.txt
Log Message:
Move open specification issues into their own document
--- NEW FILE: spec-issues.txt ---
(This appears to be a binary file; contents omitted.)
Index: E2E-spec.txt
===================================================================
RCS file: /home/minion/cvsroot/doc/spec/E2E-spec.txt,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -d -r1.4 -r1.5
--- E2E-spec.txt 30 Jun 2003 17:35:32 -0000 1.4
+++ E2E-spec.txt 14 Jul 2003 22:15:59 -0000 1.5
@@ -68,8 +68,6 @@
A.1. Appendix: Versioning and alphas
- X. Open questions
-
1. Introduction
This document is an adjunct to the main Type III (Mixminion) Mix
@@ -790,8 +788,3 @@
'0.x' instead (currently '0.1' for all versions in this document).
Production versions MUST NOT retain backward compatibility
with pre-production releases.
-
-X. Open issues
-
- 1. Mail gateways. We should specify these.
-
Index: dir-spec.txt
===================================================================
RCS file: /home/minion/cvsroot/doc/spec/dir-spec.txt,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -d -r1.7 -r1.8
--- dir-spec.txt 7 Jul 2003 16:50:11 -0000 1.7
+++ dir-spec.txt 14 Jul 2003 22:15:59 -0000 1.8
@@ -53,8 +53,6 @@
A.1. Appendix: Versioning and alphas
A.2. Appendix: Suggested path selection algorithm
- X. Open questions
-
1. Introduction
For a Mix network to provide anonymity to its users, it is vital
@@ -647,104 +645,3 @@
random, with replacement, avoiding any sequence of two consecutive
server descriptors with the same nickname.
-X. Open problems
-
- Because of possible partitioning attacks related to accidentally or
- maliciously unsynchronized servers, the presence of multiple directory
- servers presents sever security issues. Since solving these issues is
- an active research project, we leave them for a later draft.
-
- Issues include: How do directory servers synchronize?
- What happens when they disagree? How many servers must a client
- contact before he/she has enough information? How do we catch
- dishonest directory servers?
-
- * * *
-
- Also: statistics information. Also: we should think about avoiding
- catastrophic failure modes if directories _do_ fail or
- change. -NM
-
- * * *
-
- 2. Description of mixing algorithm should go in descriptor blocks. -NM
- [XXXX Unless the mixing method requires special packaging of the
- message we could require the servers to specify the amount
- of anonymity that they expect to give to each message. The
- information theoretic one presented by myself and Andrei
- could do the job quite well. -GD]
-
- * * *
-
- 1. Statistics Information Exchange format
- [Not for first cut]
-
- 2. Specify: verification for directories.
- [not for first cut]
- [Actually, we may need these first two pieces for Mixminion 1.0;
- else we won't be deployable. -NM]
-
- 3. Automatic retrieval of Server Information
- [XXXX I think it is important to have a standard way to query a
- server given an IP and a port. -GD]
-
- [Why? What's wrong with having the server upload its information to a
- directory server? (Not that I disagree, but I want to know the
- application for this. Clients can't use it without leaking which
- servers they're interested in, and giving servers the opportunity to
- lie to clients. What's the upside?) -NM]
-
- [I believe that this will make it more easy to construct Directory
- servers. For some reason I have the feeling that it will scale
- better if directory servers know about mixes (and can query them
- automatically) rather than the other way around (mixes knowing
- about directory servers). This way one can run independently a
- directory server, without any collaboration from the mix network
- (other than the ability to request info).
-
- Let's not forget that the mixes *sign* their information with a
- long term key, therefore after you establish that you trust a
- signing key to belong to an honest server, the operation of
- querying a directory server for updates is simply a question of
- transport and not of trust. Of course you still trust them to give
- you a information on a complete set of servers, but this can also
- be checked. It is also true that the a client requesting only the
- information on the servers it is about the use will ruin its
- anonymity. On the other hand if key updates are not frequent, then
- the client can slowly update its database in the background.
-
- Even more possibilities open up if each mix server give on request
- not only their information but also what they think the state of
- other servers, they have contacted in the past, is. This way each
- server you might contact will give you a set of other servers,
- that can be used by clients to construct a complete picture. Which
- ones are to be trusted is of course an orthogonal issue, but once
- it is decided the updated information could flow very
- quickly. (this is in fact a gossip protocol)
-
- These are the reasons why I think it might be a good idea to have
- automatic on request information from servers. -GD]
-
- [Hm. You may have a point. I'm still going to suggest that we do
- not do this yet, for a few reasons.
-
- First, we need a way for servers to publish their descriptors to
- directory servers. (Otherwise, a directory server couldn't learn
- about new servers for the first time.) In other words, a push
- mechanism is needed no matter what. On the other hand, directory
- servers may or may not need a pull mechanism: we do not yet have a
- design that requires this. Let's not build it till we have a use
- for it.
-
- Second, it's a bit tricky to specify *which* descriptor a server
- should return. Today's? Tomorrow's? All the ones it knows about?
-
- Third, (this is a variant of 'First') because client use of this
- feature is prone to misuse, we should only provide it to clients
- wrapped in some safe mechanism. That safe mechanism has yet to be
- specified.
-
- Therefore, I'm going to suggest that we call this feature possibly
- desirable... but that we should first design directories or whatever
- other node discovery mechanisms *may* want this feature before we
- decide that to implement the feature itself. -NM]
Index: minion-spec.txt
===================================================================
RCS file: /home/minion/cvsroot/doc/spec/minion-spec.txt,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -d -r1.7 -r1.8
--- minion-spec.txt 26 Jun 2003 03:04:03 -0000 1.7
+++ minion-spec.txt 14 Jul 2003 22:15:59 -0000 1.8
@@ -80,7 +80,7 @@
3.2.4.3. Constructing the packet
3.2.5. Processing a Type III packet
3.2.5.1. Replay avoidance
- 3.2.5.2. Message delivery.
+ 3.2.5.2. Message pooling and delivery.
3.3. SURB exchange formats
4. Transport protocol
@@ -88,9 +88,6 @@
A.2. Appendix: Compatibility with Type II mixes
A.3. Appendix: Versioning and alphas
- X. Open questions
-
-
1. Introduction
This document describes the operation of servers on a Type III mix
@@ -841,13 +838,27 @@
upon. The integrity of the list should be secured and the X values
lists may be made public.
-3.2.5.2. Message delivery
+3.2.5.2. Message pooling and delivery
- [XXXX writeme]
+ Instead of processing and delivering packets immediately upon
+ receipt, a node SHOULD packets as soon as possible (in order to
+ prevent linking in the case of compromise), but MUST accumulate a
+ batch of deliverable packets before delivering any of them (in
+ order to frustrate traffic analysis).
+
+ Nodes SHOULD choose a batching strategy that blends messages with
+ one another even in the event of a flooding or n-1 attack; such an
+ algorithm is given in Appendix A.3 below.
+
+ If a packet or message cannot be delivered immediately due to a
+ (possibly) transient error, the node SHOULD retry the message
+ periodically until either it can be delivered, or a until a given
+ interval has passed. After the interval, the packet or message
+ is discarded.
3.3. SURB exchange formats.
- This section describes how to encode messages with
+ This section describes how to encode messages with XXXX.
A SURB can be encoded in a standard binary or ASCII format.
@@ -1123,42 +1134,3 @@
'0.x' instead (currently '0.3' for packets, '0.2' for MMTP, and
'0.1' for everything else). Production versions MUST NOT retain
backward compatibility with pre-production releases.
-
-X. Open questions
-
-3. We should specify: are 'DROP'-type messages dropped before they go
- into the mix pool, or after they're pulled from the pool?
-
- [Before. -NM]
- [My feeling is After, but I should think about it... -GD]
- [Roger seemed pretty sure that it should be 'before', but I don't
- remember why. Roger? -NM
-
-4. We should specify: what happens when a message is undeliverable?
-
- [We retry for a while, then drop it. -NM]
- [Specifically: we retry the message with subsequent message pools
- until it is delivered, or until a certain amount of time has
- passed. -NM]
-
-3. When do dummy messages get generated?
- [Current hypothesis: As a first cut, we're going to have nodes add
- dummies to the outgoing batch every mix interval, with a geometric
- distribution, with 5 hops, with the sender as the last hop. -NM]
-
-4. When does link padding get generated?
- [Both active research areas; not for first cut]
-
-[XXXX
- WRT The pooling rule
-
- Paul and/or Andrei describe a variant that checks N>=POOL_SIZE+THRESHOLD,
- with THRESHOLD>= 1. Roger claims (verbally) that he isn't sure whether
- this would buy us anything, since (he says) adding 1 to POOL_SIZE would
- always increase anonymity more than adding 1 to THRESHOLD. Once they've
- come to some agreement, maybe we should do that instead.
-
- Then there are binomial mixes, where instead of sending b messages,
- you send each message with probability=b/POOLSIZE. Roger/Paul/Andrei
- seem to like those, but I don't have a clear sense of how sure they are,
- and how much everyone agrees with them. -NM]