[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[minion-cvs] Minor edits; remove nymserer and C api-- those are done
Update of /home/minion/cvsroot/doc/spec
In directory moria.mit.edu:/tmp/cvs-serv23554
Modified Files:
spec-issues.txt
Log Message:
Minor edits; remove nymserer and C api-- those are done
Index: spec-issues.txt
===================================================================
RCS file: /home/minion/cvsroot/doc/spec/spec-issues.txt,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -d -r1.2 -r1.3
--- spec-issues.txt 24 Jul 2003 03:33:21 -0000 1.2
+++ spec-issues.txt 3 Aug 2003 07:30:38 -0000 1.3
@@ -49,8 +49,7 @@
3.6. Automatic retrieval of server information
3.7. Jurisdictions and twins
4. Unspecified components
- 4.1. Nymserver
- 4.2. Standard API
+ 4.1. RFC822-style interface
0. Meta-issues
@@ -117,6 +116,9 @@
cache the result of the lookup until a connection fails, in order to
prevent spoofing attacks.
+ [Peter says we should use TTLs instead so you can move a server
+ without shutting down the old one. Sounds good.]
+
Pro:
- Servers with dynamically assigned IP become viable.
- Changing a server's IP no longer delays traffic until the
@@ -148,7 +150,7 @@
Right now, the network may be too easy to DOS. In particular, there
are unpleasantly high work multipliers for attacks that send junk
- packets to nodes, forcing the nodes to RSA-decrypt the packets them
+ packets to nodes, forcing the nodes to RSA-decrypt the packets
before they can find out that they are invalid.
Another attack arises because RSA encryption is far cheaper than
@@ -213,7 +215,7 @@
way to send multi-part messages.
This functionality *may* take the format of a canonical subset of
- MIME, but Lucky thinks that such a thing would drive us into
+ MIME, but Lucky thinks that such a thing would drive us into a
Lovecraftian state of madness.
2.3. Improved K-of-N algorithm
@@ -312,7 +314,7 @@
3.4. Unadvertised broken links
We may or may not want a way for a directory to advertise that,
- although N1 and N2 both work, and N1 and N2 both claim allow
+ although N1 and N2 both work, and N1 and N2 both claim to allow
messages from one other, the N1-N2 link is broken nonetheless.
3.5. Anonymity information in descriptor blocks
@@ -336,7 +338,7 @@
There may be some value in allowing others to get this information
by querying the nodes themselves.
- Here's an exchange between George an Nick on the subject.
+ Here's an exchange between George and Nick on the subject.
[XXXX I think it is important to have a standard way to query a
server given an IP and a port. -GD]
@@ -429,35 +431,7 @@
standardized, though they would not form a part of any of the
current specification documents.
-4.1. Nymserver
-
- We need a standard nymserver protocol.
-
- The consensus seems to be toward a POP-like implementation that
- would allow clients to request lists of message headers, and delete
- or retrieve each message at their discretion.
-
- (If nymservers relay every message to the client automatically, an
- attacker could DOS a client by exhausting their store of SURBs, or
- mount a traffic analysis attack by flooding the nym with spam.)
-
- There is probably some value to allowing clients to pre-load a
- nymserver with a set of SURBs, in order to allow reduced message
- latency.
-
- In recent discussion, on a.p.a.s, some users have suggested that nym
- users ought to have a way to tell their nymservers to drop traffic
- according to certain rules. This may be useful, but may allow
- partitioning.
-
- There is also some tension between the requirement that nymsevers
- should encrypt information as soon as it arrives, and the
- requirement that nymservers should look for duplicate information to
- discourage floods and DOS attacks.
-
-4.2. Standard API
-
- Somebody should write a standard API for invoking type III clients.
+4.1. RFC822-style interface
- There may be value in specifying both an in-process and an
- out-of-process (CLI) interface.
+ It'd be nice to have a standard way to feed a single text file to
+ a CLI and get a message sent.