[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[minion-cvs] Fragment issues (PLEASE READ!) and other cleanups.
Update of /home/minion/cvsroot/doc/spec
In directory moria.mit.edu:/tmp/cvs-serv17065/doc/spec
Modified Files:
E2E-spec.txt dir-spec.txt minion-spec.txt spec-issues.txt
Log Message:
Fragment issues (PLEASE READ!) and other cleanups.
The important changes are in E2E-spec -- There was an issue before
where the destination address of a fragmented message would sit,
unencrypted, at the exit node, until enough of the pieces were
retrieved to reconstruct the message. Now the window of exposure is
smaller.
Index: E2E-spec.txt
===================================================================
RCS file: /home/minion/cvsroot/doc/spec/E2E-spec.txt,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -d -r1.5 -r1.6
--- E2E-spec.txt 14 Jul 2003 22:15:59 -0000 1.5
+++ E2E-spec.txt 24 Jul 2003 03:33:21 -0000 1.6
@@ -14,8 +14,6 @@
specification for Type III remailers. It is not a final version.
It has not yet been submitted to any standards body.
- TODO: See open issues section.
-
Abstract
This document describes a formats and algorithms used by client
@@ -65,6 +63,8 @@
3.3.2. Formatting: Message body
3.3.3. Delivery
3.3.4. Server descriptor section
+ 3.4. Fragments
+ 3.4.1. Server descriptor section
A.1. Appendix: Versioning and alphas
@@ -385,6 +385,46 @@
We then transmit each payload with its corresponding tag.
+2.2.2.1. Plaintext forward messages and fragments
+
+ We require some additional complexity to minimize the time in which
+ the destination of a plaintext forward fragmented message is
+ decrypted in remailer's storage.
+
+ Unlike encrypted forward and reply fragmented messages, which are
+ delivered packet-by-packet to their recipients, plaintext forward
+ fragmented messages are reassembled by an exit node before
+ delivery. (We cannot require that their recipients reassemble
+ them, since we assume that the recipient of a plaintext forward
+ message may not be running any anonymity software.)
+
+ Having exit nodes reassemble fragments introduces two problems:
+
+ 1) Because the exit node must hold fragments until they can be
+ reassembled, an attacker can attempt to exhaust the exit
+ node's resources by flooding it with fragments for messages
+ that never arrive.
+
+ 2) Because the recipient of a type III packet is encoded in its
+ final subheader, an attacker who compromises a type III
+ remailer can read the identities of all the users who have
+ pending plaintext forward messages.
+
+ We specify a solution to 2 here. When generating plaintext forward
+ fragmented messages, the message generator uses a routing type of
+ "FRAGMENT" (0x0103), an empty routing into, and prepends the
+ following fields to the message body before fragmenting it:
+
+ RS Routing size 2 octets
+ RT Routing type 2 octets
+ RI Routing info (variable length; RS=Len(RI))
+ (These fields are as described in minion-spec.txt.)
+
+ Thus, the destination of a message is not retrievable by the exit
+ node until enough fragments have been received to decrypt the
+ message itself. In this way, we minimize the window in which the
+ identity of a recipient is visible to the exit node.
+
2.2.3. Generating encrypted forward messages
To send an encrypted forward message M to a user with an RSA public
@@ -555,6 +595,39 @@
alert the user and require explicit confirmation before
decompressing the message.
+2.3.3. Reconstruction issues
+
+ When a server receives a plaintext forward packet containing a
+ fragment of a message, it should behave as follows:
+
+ - If the server does not support reconstruction, or if the hash
+ of the packet is invalid, it drops the packet.
+
+ - From the declared message size of the message, it calculates
+ the number of packets it expects. If this number is higher
+ than the maximum number of packets the server is willing to
+ construct, it drops the packet.
+
+ - If the server has already logged this message ID as finished,
+ it drops the packet.
+
+ - If the server has other packets with this message ID, and
+ those packets have a different message size, it drops all
+ packets with this message ID and logs this message ID as
+ finished. If the server encounters multiple packets with the
+ same message ID and packet index, it drops all packets with
+ that message ID, and marks the message ID as finished.
+
+ - The server stores this packet pending reconstruction. If
+ enough packets are held for this message ID to reconstruct
+ the message, the server reconstructs the message (as
+ described below), delivers it, deletes all fragment packets
+ for this message ID, and marks the message ID as finished.
+
+ To prevent denial of service attacks, a server MAY delete old
+ fragments when it is low on disk space. [XXXX is this the best
+ approach?]
+
3. Delivery
This section describes the standard message delivery types provided
@@ -581,11 +654,15 @@
of "Decoding-handle". Otherwise, the "Decoding-handle" header
MUST be omitted.
+ [XXXX remove this -- it's no longer accurate. We require that exit
+ nodes reconstruct fragments now.
+
When encountering a plaintext fragment, an exit node that does not
support message reconstruction, or that is not willing to
reconstruct a message of the given size, SHOULD deliver the
fragment as-is, with armor described above, and "Message-type" set
to "fragment".
+ XXXX remove]
When encoding a plaintext Type III message, exit nodes MAY apply
OpenPGP ASCII armor if the message contains characters other than
@@ -724,11 +801,12 @@
Servers that support MBOX delivery MAY include a [Delivery/MBOX]
section, containing the entry "Version: 1.0". Other servers
MUST NOT include a [Delivery/MBOX] section.
-
+
If the server supports message reconstruction, the section MAY
include a "Maximum-size" line, containing the maximum permitted
- message size in KB (before compression).
-
+ message size in KB (before compression). [XXXX is "before"
+ reasonable?]
+
3.3. SMTP
The routing type 0x100 corresponds to SMTP (email) delivery.
@@ -776,11 +854,24 @@
Servers that support SMTP delivery MAY include a [Delivery/SMTP]
section, containing the entry "Version: 1.0". Other servers
MUST NOT include a [Delivery/SMTP] section.
-
+
If the server supports message reconstruction, the section MAY
include a "Maximum-size" line, containing the maximum permitted
message size in KB (before compression). [XXXX is "before"
reasonable?]
+
+3.4. Fragments
+
+3.4.1. Server descriptor section
+
+ When a server supports message reconstruction, it MAY include a
+ "[Delivery/Fragmented]" section as described here. Other servers
+ MUST NOT include a "[Delivery/Fragmented]" section.
+
+ The section, if present, MUST contain a 'Version' entry, with the
+ value "1.0". It also MUST contain a "Maximum-Fragments" line,
+ containing the maximum size (in fragments) of a message that the
+ server is willing to reconstruct.
A.1. Apendix: versioning and alphas
Index: dir-spec.txt
===================================================================
RCS file: /home/minion/cvsroot/doc/spec/dir-spec.txt,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -d -r1.8 -r1.9
--- dir-spec.txt 14 Jul 2003 22:15:59 -0000 1.8
+++ dir-spec.txt 24 Jul 2003 03:33:21 -0000 1.9
@@ -14,11 +14,6 @@
specification for Type III Remailers. It is not a final version.
It has not yet been submitted to any standards body.
- TODO:
- - See open issues section
- - Resolve XXXXs
- - Final directory operation.
-
Abstract
This document describes the protocols and message formats used by
Index: minion-spec.txt
===================================================================
RCS file: /home/minion/cvsroot/doc/spec/minion-spec.txt,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -d -r1.8 -r1.9
--- minion-spec.txt 14 Jul 2003 22:15:59 -0000 1.8
+++ minion-spec.txt 24 Jul 2003 03:33:21 -0000 1.9
@@ -14,22 +14,13 @@
specification for Type III remailers. It is not a final version.
It has not yet been submitted to any standards body.
- It supersedes the old "minion-spec.tex", which was never really a
- TeX file in the first place. When you edit it, try to keep it
- looking like an RFC.
+ (This draft supersedes the old "minion-spec.tex", which was never
+ really a TeX file in the first place. When you edit it, try to
+ keep it looking like an RFC.)
The organization of this document loosely follows the structure
of RFC2440.
- TODO:
- - Resolve XXXXs, esp: 3.2.3 - 4.
- - Describe crossover and server operations
- - Who else to add to authors?
- - We should add an ACKS section where we put all the people that
- have contributed to the project.
- - Process E2E-spec
- - Incorporate Text-spec
-
Abstract
This document describes the message formats and protocols required
@@ -156,7 +147,7 @@
4. The sender chooses a list of the mixes from step 3 to
constitute a path through the mix-net. [Described in
- "path-spec.txt".]
+ "E2E-spec.txt".]
5. The sender successively wraps the chunk in a layer of
encryption for each node in the chosen path, from last to
@@ -483,9 +474,10 @@
0x0100-0x0FFF: PREDEFINED DELIVERY TYPES.
- 0x0100 SMTP [See "E2E-spec.txt"]
- 0x0101 MBOX [See "E2E-spec.txt"]
- 0x0102 MIX2 (EMAIL ADDRESS: variable). Type II remailer support.
+ 0x0100 SMTP [See "E2E-spec.txt"]
+ 0x0101 MBOX [See "E2E-spec.txt"]
+ 0x0102 MIX2 (EMAIL ADDRESS: variable). Type II remailer support.
+ 0x0103 FRAGMENT (Fragment to be reassembled by exit node; see E2E-spec)
0x1000-0xEFFF: UNALLOCATED
Index: spec-issues.txt
===================================================================
RCS file: /home/minion/cvsroot/doc/spec/spec-issues.txt,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -d -r1.1 -r1.2
--- spec-issues.txt 14 Jul 2003 22:15:59 -0000 1.1
+++ spec-issues.txt 24 Jul 2003 03:33:21 -0000 1.2
@@ -22,6 +22,7 @@
Table of Contents
Status of this Document X
+ 0. Meta-issues
1. Issues in MIX3:1: 'minion-spec.txt'
1.1. Disposition of 'DROP' messages
1.2. Generation of dummy messages and link padding
@@ -50,6 +51,13 @@
4. Unspecified components
4.1. Nymserver
4.2. Standard API
+
+0. Meta-issues
+
+ The authors lists may be incomplete.
+
+ We should add an ACKS section where we put all the people that have
+ contributed to the project.
1. Issues in Mix3:1: 'minion-spec.txt'