idnits 2.17.1 draft-sassaman-mixmaster-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 787 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 38 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 212 has weird spacing: '... rate perc...' == Line 500 has weird spacing: '... Nm support...' == Line 501 has weird spacing: '... Np support...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2004) is 7375 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC 2311' is defined on line 720, but no explicit reference was found in the text == Unused Reference: 'Schneier 1996' is defined on line 730, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Chaum 1981' -- Possible downref: Non-RFC (?) normative reference: ref. 'Mazieres 1998' -- Possible downref: Non-RFC (?) normative reference: ref. 'Moeller 1998' ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 1036 (Obsoleted by RFC 5536, RFC 5537) ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Downref: Normative reference to an Historic RFC: RFC 1421 ** Downref: Normative reference to an Informational RFC: RFC 1952 ** Downref: Normative reference to an Historic RFC: RFC 2311 ** Obsolete normative reference: RFC 2437 (Obsoleted by RFC 3447) ** Obsolete normative reference: RFC 2440 (Obsoleted by RFC 4880) -- Possible downref: Non-RFC (?) normative reference: ref. 'Schneier 1996' Summary: 13 errors (**), 0 flaws (~~), 8 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet-Draft Ulf Moeller 2 Expires: August 31, 2004 3 Lance Cottrell 4 Anonymizer Inc. 5 Peter Palfrader 6 The Mixmaster Project 7 Len Sassaman 8 Nomen Abditum Services 9 February 2004 11 Mixmaster Protocol Version 2 12 draft-sassaman-mixmaster-00.txt 14 Status of This Memo 16 This document is an Internet-Draft and is subject to all provisions 17 of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other 26 documents at any time. It is inappropriate to use Internet- 27 Drafts as reference material or to cite them other than as 28 "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/1id-abstracts.html 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 This Internet-Draft will expire on July 31, 2004. 38 Copyright Notice 40 Copyright (C) The Internet Society (2004). All Rights Reserved. 42 Abstract 44 Most e-mail security protocols only protect the message body, leaving 45 useful information such as the the identities of the conversing 46 parties, sizes of messages and frequency of message exchange open to 47 adversaries. This document describes Mixmaster (version 2), a mail 48 transfer protocol designed to protect electronic mail against traffic 49 analysis. 51 Mixmaster is based on D. Chaum's mix-net protocol. 52 A mix (remailer) is a service that forwards messages, using public key 53 cryptography to hide the correlation between its inputs and outputs. 54 Sending messages through sequences of remailers achieves anonymity and 55 unobservability of communications against a powerful adversary. 57 Table of Contents 59 1. Introduction 60 2. The Mix-Net Protocol 61 2.1 Message Creation 62 2.2 Remailing 63 2.3 Message Reassembly 64 2.4 Remixing 65 3. Pool Behavior 66 3.1 Timed Dynamic Pool Mix Algorithm 67 3.2 Dummy Traffic 68 4. Message Format 69 4.1 Payload Format 70 4.2 Cryptographic Algorithms 71 4.3 Packet Format 72 4.3.1 Header Section Format 73 4.3.2 Body Format 74 4.4 Mail Transport Encoding 75 5. Key Format 76 5.1 Key Rotation 77 6. Administrative Commands 78 7. Delivery of Anonymous Messages 79 8. Security Considerations 80 9. Acknowledgments 81 10. References 82 11. Authors' Addresses 84 1. Introduction 86 This document describes a mail transfer protocol designed to protect 87 electronic mail against traffic analysis. Most e-mail security 88 protocols only protect the message body, leaving useful information 89 such as the the identities of the conversing parties, sizes of 90 messages and frequency of message exchange open to adversaries. 92 Message transmission can be protected against traffic analysis by the 93 mix-net protocol. A mix (remailer) is a service that forwards 94 messages, using public key cryptography to hide the correlation 95 between its inputs and outputs. If a message is sent through a 96 sequence of mixes, one trusted mix is sufficient to provide anonymity 97 and unobservability of communications against a powerful 98 adversary. Mixmaster is a mix-net implementation for electronic mail. 100 This memo describes version 2 of the Mixmaster message format, as used on 101 the Internet since 1995. 103 2. The Mix-Net Protocol 105 The mix-net protocol [Chaum 1981] allows one to send messages while hiding 106 the relation of sender and recipient from observers 107 (unobservability). It also provides the sender of a message with the 108 ability to remain anonymous to the recipient (sender anonymity). If 109 anonymity is not desired, authenticity and unobservability can be 110 achieved at the same time by transmitting digitally signed messages. 112 This section gives an overview over the protocol used in Mixmaster. The 113 mixing algorithm is specified in section 3, and the message format is 114 specified in section 4. 116 2.1 Message Creation 118 To send a message, the user agent splits it into parts of fixed size, 119 which form the bodies of Mixmaster packets. If sender anonymity is 120 desired, care should be taken not to include identifying information 121 in the message. The message may be compressed. 123 The sender chooses a sequence of up to 20 remailers for each 124 packet. The final remailer must be identical for all packets. 126 The packet header consists of 20 sections. For a sequence of n 127 remailers, header sections n+1, ... , 20 are filled with random 128 data. For each section i := n down to 1, the sender generates a 129 symmetric encryption key, which is used to encrypt the body and 130 all following header sections. This key, together with other control 131 information for the remailer, is included in the i-th header section, 132 which is then encrypted with the remailer's public key. The resulting 133 message is sent to the first remailer in an appropriate transport 134 encoding. 136 To increase reliability, redundant copies of the message may be sent 137 through different paths. The final remailer must be identical for all 138 paths, so that duplicates can be detected and the message is delivered 139 only once. 141 2.2 Remailing 143 When a remailer receives a message, it decrypts the first header 144 section with its private key. By keeping track of a packet ID, the 145 remailer verifies that the packet has not been processed before. The 146 integrity of the message is verified by checking the packet length and 147 verifying message digests included in the packet. Then the first 148 header section is removed, the others are shifted up by one, and the 149 last section is filled with random padding. All header sections and 150 the packet body are decrypted with the symmetric key found in the 151 header. This reveals a public key-encrypted header section for the 152 next remailer at the top, and removes the old top header 153 section. Transport encoding is applied to the resulting message. 155 The remailer collects several encrypted messages before sending the 156 resulting messages in random order. Thus the relation between the 157 incoming and outgoing messages is obscured to outside adversaries even 158 if the adversary can observe all messages sent. The message is 159 effectively anonymized by sending it through a chain of independently 160 operated remailers. 162 2.3 Message Reassembly 164 When a packet is sent to the final remailer, it contains an indication 165 that the chain ends at that remailer, and whether the packet contains 166 a complete message or part of a multi-part message. If the packet 167 contains the entire message, the packet body is decrypted and after 168 reordering messages the plain text is delivered to the recipient. For 169 partial messages, a message ID is used to identify the other parts as 170 they arrive. When all parts have arrived, the message is reassembled, 171 decompressed if necessary, and delivered. If the parts do not arrive 172 within a time limit, the message is discarded. 174 Only the last remailer in the chain can determine whether packets are 175 part of a certain message. To all the others, they are completely 176 independent. 178 2.4 Remixing 180 Some remailers may understand multiple remailer protocols. In the interest of 181 creating a unified anonymity set, remailers which speak multiple remailer 182 protocols should attempt to remix messages that use the older protocols wheneve 183 r 184 possible. 186 When a remailer receives a message in the older protocol format, it should 187 determine if the message destination is another remailer which also speaks the 188 Mixmaster protocol. If the remailer knows the Mixmaster public key for the next 189 hop, it should process the message normally, but instead of sending the message 190 to its next hop, treat the processed message as opaque data which will comprise 191 the body of a Mixmaster message. The remailer should then create a Mixmaster 192 message with this body to be delivered to the next hop remailer. 194 If the remailer receives a Mixmaster message that, when decrypted, reveals a 195 message of another protocol which the remailer speaks, it should process the 196 message as though it had been delivered in the other protocol format initially. 198 3. Pool Behavior 200 3.1 Timed Dynamic Pool Mix Algorithm 202 In order to obfuscate the link between incoming and outgoing messages, 203 Mixmaster uses a pooling scheme. Messages that are to be forwarded 204 anonymously are stored in a pool. In regular intervals the remailer fires 205 and sends some random messages from the pool to either the next hop or 206 their final recipients. 208 The pooling scheme used in Mixmaster is a "Timed Dynamic Pool Mix", which has 209 the following three parameters: 210 t mixing interval 211 min minimum number of messages in the pool 212 rate percentage of messages to be send in one round 214 Every t seconds: 215 - Let n be the number of messages currently in the pool 216 - count is the smaller of (n - min) and (n * rate), or 0 if 217 (n - min) is negative. 218 - Select count random messages from the pool and send them. 220 3.2. Dummy Traffic 222 "Dummy messages" are multi-hop messages of type NULL with four randomly 223 selected nodes as their chain. Chains are selected such that no node 224 will appear twice in the chain unless separated by two other nodes in 225 the chain. 227 Older versions of Mixmaster (2.0.4 - 2.9.0) allowed for the creation of 228 dummy message cover traffic, but provided no automated means for 229 introducing this dummy traffic into the system. Beginning in version 230 3.0, Mixmaster employs an internal dummy policy. 232 Every time a message is placed in the pool, the remailer chooses a 233 random number from a geometric distribution and creates that many dummy 234 messages which are also placed in the pool. 236 Similarly, prior to each execution of the mixing algorithm described in 237 section 3.1, the remailer selects a random number from a different 238 geometric distribution and adds that many dummy messages to the pool as 239 well. 241 The distributions' parameters are chosen so that on average the remailer 242 creates one dummy for every 32 messages coming in and one every 9 mixing 243 rounds. 245 4. Message Format 247 4.1 Payload Format 249 The Mixmaster message payload can be an e-mail message, a Usenet 250 message or a dummy message. 252 The messages use the formats specified in [RFC 822] and [RFC 1036] 253 respectively, prepended with data specifying the payload type. An 254 additional, more restricted method of specifying message header lines 255 is defined for reasons of backward compatibility. 257 The payload format is as follows: 259 Number of destination fields [ 1 byte] 260 Destination fields [ 80 bytes each] 261 Number of header line fields [ 1 byte] 262 Header lines fields [ 80 bytes each] 263 User data section [ up to ~2.5 MB] 265 Each destination field consist of a string of up to 80 ASCII characters, 266 padded with null-bytes to a total size of 80 bytes. The following 267 strings are defined: 269 null: dummy message 270 post: Usenet message 271 post: [newsgroup] Usenet message 272 [address] e-mail message 274 If no destination field is given, the payload is an e-mail message. 276 If the destination field is "post: [newsgroup]", a "Newsgroups: 277 [newsgroup]" field is added to the header of the resulting message. If 278 the destination field is of the fourth type, a "To: [address]" field 279 is added to the header of the resulting message. [address] and 280 [newsgroup] are strings of ASCII characters. If the message 281 is a dummy message the node should discard it. 283 Message headers can be specified in header line fields. Each header 284 line field consists of a string of up to 80 ASCII characters, padded 285 with null-bytes to a total size of 80 bytes. 287 There are three types of user data sections: 289 A compressed user data section begins with the GZIP identification 290 header (31, 139). It contains another user data section. The data are 291 compressed using GZIP [RFC 1952]. The GZIP operating system field must 292 be set to Unix, and file names must not be given. Compression may be 293 used if the capabilities attribute of the final remailer contains the 294 flag "C". 296 An RFC 822 user data section begins with the identification "##" 297 (35, 35, 13). It contains an e-mail message or a Usenet message as 298 specified in [RFC 822] and [RFC 1036]. This type cannot be used if 299 the final remailer uses a Mixmaster software version prior to 2.0.4. 301 A user data section not beginning with one of the above identification 302 strings contains only the body of the message. When this type of user 303 data section is used, the message header fields must be included in 304 destination and header line fields. 306 The payload is limited to a maximal size of 2610180 bytes. Individual 307 remailers may use a smaller limit. 309 Remailer operators can choose to remove header fields supplied by the 310 sender and insert additional header fields, according to local policy 311 (see section 5). 313 4.2 Cryptographic Algorithms 315 The asymmetric encryption operation in Mixmaster version 2 uses RSA 316 with 1024 bit RSA keys and the PKCS #1 v1.5 (RSAES-PKCS1-v1_5) padding 317 format [RFC 2437]. The symmetric encryption uses EDE 3DES with cipher 318 block chaining (24 byte key, 8 byte initialization vector) [Schneier 319 1996]. MD5 [RFC 1321] is used as the message digest algorithm. 321 4.3 Packet Format 323 A Mixmaster packet consists of a header containing information for the 324 remailers, and a body containing payload data. To ensure that 325 packets are indistinguishable, the size of these encrypted data fields 326 is fixed. 328 The packet header consists of 20 header sections (specified in 329 section 3.3.1) of 512 bytes each, resulting in a total header size 330 of 10240 bytes. The header sections -- except for the first one -- and 331 the packet body are encrypted with symmetric session keys specified in 332 the first header section. 334 4.3.1 Header Section Format 336 Public key ID [ 16 bytes] 337 Length of RSA-encrypted data [ 1 byte ] 338 RSA-encrypted session key [ 128 bytes] 339 Initialization vector [ 8 bytes] 340 Encrypted header part [ 328 bytes] 341 Padding [ 31 bytes] 343 Total size: 512 bytes 345 To generate the RSA-encrypted session key, a random 24 byte Triple-DES 346 key is encrypted with RSAES-PKCS1-v1_5, resulting in 128 bytes (1024 347 bits) of encrypted data. This Triple-DES key and the initialization 348 vector provided in clear are used to decrypt the encrypted header part. 349 They are not used at other stages of message processing. 351 The 328 bytes of data encrypted to form the encrypted header part are 352 as follows: 354 Packet ID [ 16 bytes] 355 Triple-DES key [ 24 bytes] 356 Packet type identifier [ 1 byte ] 357 Packet information [depends on packet type] 358 Timestamp [ 7 bytes] 359 Message digest [ 16 bytes] 360 Random padding [fill to 328 bytes] 362 The possible packet type identifiers are: 364 Intermediate hop 0 365 Final hop 1 366 Final hop, partial message 2 368 The packet information depends on the packet type identifier, as follows: 370 Packet type 0 (intermediate hop): 371 19 Initialization vectors [152 bytes] 372 Remailer address [ 80 bytes] 374 Packet type 1 (final hop): 375 Message ID [ 16 bytes] 376 Initialization vector [ 8 bytes] 378 Packet type 2 (final hop, partial message): 379 Chunk number [ 1 byte ] 380 Number of chunks [ 1 byte ] 381 Message ID [ 16 bytes] 382 Initialization vector [ 8 bytes] 384 Packet ID: randomly generated packet identifier. 386 Triple-DES key: used to encrypt the following header sections and the 387 packet body. 389 Initialization vectors: For packet type 1 and 2, the IV is used to 390 symmetrically encrypt the packet body. For packet type 0, there is one IV 391 for each of the 19 following header sections. The IV for the last header 392 section is also used for the packet body. 394 Remailer address: e-mail address of next hop. 396 Message ID: randomly generated identifier unique to (all chunks of) 397 this message. 399 Chunk number: Sequence number used in multi-part messages, starting 400 with 1. 402 Number of chunks: Total number of chunks. 404 Timestamp: A timestamp is introduced with the byte sequence (48, 48, 48, 405 48, 0). The following two bytes specify the number of days since Jan 1, 406 1970, given in little-endian byte order. A random number of up to 3 may be 407 subtracted from the number of days in order to obscure the origin of the 408 message. 410 Message digest: MD5 digest computed over the preceding elements of the 411 encrypted header part. 413 In the case of packet type 0, header sections 2 .. 20 and the packet body 414 each are decrypted separately using the respective initialization vectors. 415 In the case of packet types 1 and 2, header sections 2 .. 20 are ignored, 416 and the packet body is decrypted using the given initialization vector. 418 4.3.2 Body Format 420 The message payload (section 3.1) is split into chunks of 10236 421 bytes. To each chunk, its length is prepended as a 4 byte 422 little-endian number to form the body of a Mixmaster packet. 424 A message may consist of up to 255 packets. 426 4.4 Mail Transport Encoding 428 Mixmaster packets are sent as text messages [RFC 822]. The RFC 822 429 message body has the following format: 431 :: 432 Remailer-Type: Mixmaster [version number] 434 -----BEGIN REMAILER MESSAGE----- 435 [packet length ] 436 [message digest] 437 [encoded packet] 438 -----END REMAILER MESSAGE----- 440 The length field always contains the decimal number "20480", since the 441 size of Mixmaster packets is constant. An MD5 message digest [RFC 442 1321] of the (un-encoded) packet is encoded in base64. 444 The packet itself is encoded in base 64 encoding [RFC 1421], broken 445 into lines of 40 characters (except that the last line is shorter). 447 5. Key Format 449 Remailer public key files consist of a list of attributes and a 450 public RSA key: 452 [attributes list] 454 -----Begin Mix Key----- 455 [key ID] 456 [length] 457 [encoded key] 458 -----End Mix Key----- 460 The attributes are listed in one line separated by spaces. Individual 461 attributes must not contain whitespace: 463 identifier: a human readable string identifying the remailer 464 address: the remailer's Internet mail address 465 key ID: public key ID 466 version: the Mixmaster software version number 467 capabilities: flags indicating additional remailer capabilities 468 validity date: date from which the key is valid 469 expiration date: date of the key's expiration 471 The identifier consists of lowercase alphanumeric characters, beginning 472 with an alphabetic character. The identifier should consist of no more 473 than eight characters in length. 475 The encoded key packet consists of two bytes specifying the key length 476 (1024 bits) in little-endian byte order, and of the RSA modulus and the 477 public exponent in big-endian form using 128 bytes each, with preceding 478 null bytes for the exponent if necessary. The packet is encoded in base 64 479 [RFC 1421], and broken into lines of 40 characters each (except that the 480 last line is shorter). Its length (258 bytes) is given as a decimal 481 number. 483 The key ID is the MD5 message digest of the representation of the RSA 484 public key (not including the length bytes). It is encoded as a 485 hexadecimal string. 487 The version field consists of the protocol version number followed by a 488 colon and the software version information, limited to the ASCII 489 alphanumeric characters, plus dot (.) and dash (-). All implementations of 490 this protocol should prepend the software version with "2:" to indicate 491 Mixmaster protocol version 2. Existing implementations lacking a protocol 492 version number imply protocol version 2. 494 The capabilities field is optional. It is a list of flags represented 495 by a string of ASCII characters. Clients should ignore unknown 496 flags. The following flags are used in version 2.0.4 through 3.0: 498 C accepts compressed messages. 499 M will forward messages to another mix when used as final hop. 500 Nm supports posting to Usenet through a mail-to-news gateway. 501 Np supports direct posting to Usenet. 503 The date fields introduced in version 3.0 are optional. They are ASCII 504 date stamps in the format YYYY-MM-DD. The first date indicates the date 505 from which the key is first valid; the second date indicates its 506 expiration. If only one date is present, it is treated as the key creation 507 date. (The date stamp implies 00:00 UTC). 509 Digital signatures [RFC 2440] should be used to ensure the 510 authenticity of the key files. 512 5.1 Key Rotation 514 Beginning with version 3.0, Mixmaster offers automatic key rotation. Care 515 must be taken to minimize the possibility for partitioning attacks during 516 the key rotation window. 518 Keys are generated with a validity date and an expiration date. Mixmaster 519 clients only display keys which are currently valid and not expired. 521 Keys are valid for a 13 month period. Mixmaster remailers generate new 522 keys when the existing key's expiration date is one month or less in the 523 future. Remailers report the most recently generated key as the remailer 524 key when queried, effectively giving each key a 12 month service period. 526 Remailers continue to decrypt and process mail encrypted to expired keys 527 for one week past the expiration date on the key. One week after 528 expiration, an expired remailer key should be securely destroyed. 530 6. Administrative Commands 532 The remailer software understands a number of specific administrative 533 commands. These commands are sent via the Subject: line of an email to the 534 email address of the remailer: 536 remailer-help: returns information on using the remailer 537 remailer-key: returns the remailer's public key 538 remailer-stats: returns information on the number of messages processed 539 remailer-conf: returns local configuration information 540 remailer-adminkey: returns the public key of the remailer operator 542 Upon receiving an administrative request, the remailer returns its reply 543 to the email address specified in the Reply-To: or From: header of the 544 request. 546 The remailer-help request should return basic information on using the 547 remailer. Remailers may also accept remailer-help requests with an ISO 639 548 two-letter language code appended following a hyphen. For example, 549 remailer-help-ar will return a help file in Arabic, if available. 550 Supported languages should be listed at the beginning of the remailer-help 551 response. 553 The remailer-key request returns the remailer key as described above. It 554 may also return keys and capability information for other remailer 555 protocols supported by the remailer. 557 The remailer-stats request returns statistics on the number of messages 558 processed per day by the remailer. 560 The remailer-conf request returns local configuration information, such as 561 the version of the remailer software, the supported remailer protocols, 562 filtered headers, blocked newsgroups and domains, and the attribute 563 strings for other remailers the remailer knows about. 565 The remailer-adminkey request returns a public OpenPGP key for use in 566 communication with the remailer operator. 568 7. Delivery of Anonymous Messages 570 When anonymous messages are forwarded to third parties, remailer 571 operators should be aware that senders might try to supply header 572 fields that indicate a false identity or to send Usenet control 573 messages [RFC 1036] unauthorized, which is a problem because many news 574 servers accept control messages automatically without any 575 authentication. 577 For these reasons, remailer software should allow the operator 578 to disable certain types of message headers, and to insert headers 579 automatically. 581 Remailers usually add a "From:" field containing an address controlled 582 by the remailer operator to anonymous messages. Using the word 583 "Anonymous" in the name field allows recipients to apply scoring 584 mechanisms and filters to anonymous messages. Appropriate additional 585 information about the origin of the message can be inserted in the 586 "Comments:" header field of the anonymous messages. 588 If the recipient does not wish to receive anonymous messages, 589 unobservability of communications and authenticity can be achieved at 590 the same time by the remailer verifying that the message is 591 cryptographically signed [RFC 2440] by a known sender. 593 Anonymous remailers are sometimes used to send harassing e-mail. To 594 prevent this abuse, remailer software should allow operators to block 595 destination addresses on request. Real-life abuse and attacks on 596 anonymous remailers are discussed in [Mazieres 1998]. 598 8. Security Considerations 600 The security of the mix-net relies on the assumption that the 601 underlying cryptographic primitives are secure. In addition, specific 602 attacks on the mix-net need to be considered ([Moeller 1998] contains a 603 more detailed analysis of these attacks). 605 Passive adversaries can observe some or all of the messages sent to 606 mixes. The users' anonymity comes from the fact that a large number 607 of messages are collected and sent in random order. For that reason 608 remailers should collect as many messages as possible while keeping 609 the delay acceptable. 611 Statistical traffic analysis is possible even if single messages are 612 anonymized in a perfectly secure way: An eavesdropper may correlate 613 the times of Mixmaster packets being sent and anonymized messages 614 being received. This is a powerful attack if several anonymous 615 messages can be linked together (by their contents or because they are 616 sent under a pseudonym). To protect themselves, senders must mail 617 Mixmaster packets stochastically independent of the actual messages 618 they want to send. This can be done by sending packets in regular 619 intervals, using a dummy message whenever appropriate. To avoid 620 leaking information, the intervals should not be smaller than the 621 randomness in the delay caused by trusted remailers. 623 There is no anonymity if all remailers in a given chain collude with 624 the adversary, or if they are compromised during the lifetime of their 625 keys. Using a longer chain increases the assurance that the user's 626 privacy will be preserved, but in the same time causes lower 627 reliability and higher latency. Sending redundant copies of a message 628 increases reliability but may also facilitate attacks. An optimum must 629 be found according to the individual security needs and trust in the 630 remailers. 632 Active adversaries can also create, suppress or modify messages. Remailers 633 must check the packet IDs to prevent replay attacks. To minimize the 634 number of packet IDs that the remailer must retain, packets which bear a 635 timestamp more than a reasonable number of days in the past may be 636 discarded. Implementors should consider that packets maybe up to three 637 days younger than indicated by the timestamp, and select an expiration 638 value which allowsd sufficient time for legitimate messages to pass 639 through the network. The number of packet IDs that the remailer must 640 retain can be further minimized by discarding packet IDs for packets 641 encrypted to a key which has expired more than a week in the past. 643 Early implementations of Mixmaster did not generate a timestamp packet. 644 Implementors should be aware of the partitioning attack implications if 645 they chose to permit processing of packets without timestamps. 647 Message integrity must be verified to prevent the adversary 648 from performing chosen ciphertext attacks or replay attacks with 649 modified packet IDs, and from encoding information in an intercepted 650 message in a way not affected by decryption (e.g. by modifying the 651 message length or inducing errors). This version of the protocol does 652 not provide integrity for the packet body. Because the padding for 653 header section is random, in this version of the protocol it is 654 impossible for a remailer to check the integrity of the encrypted 655 header sections that will be decrypted by the following remailers. 656 Chosen ciphertext attacks and replay attacks are detected by verifying 657 the message digest included in the header section. 659 The adversary can trace a message if he knows the decryption of all 660 other messages that pass through the remailer at the same time. To 661 make it less practical for an attacker to flood a mix with known 662 messages, remailers can store received messages in a reordering pool 663 that grows in size while more than average messages are received, and 664 periodically choose at random a fixed fraction of the messages in the 665 pool for processing. There is no complete protection against flooding 666 attacks in an open system, but if the number of messages required is 667 high, an attack is less likely to go unnoticed. 669 If the adversary suppresses all Mixmaster messages from one particular 670 sender and observes that anonymous messages of a certain kind are 671 discontinued at the same time, that sender's anonymity is compromised 672 with high probability. There is no practical cryptographic protection 673 against this attack in large-scale networks. The effect of a more 674 powerful attack that combines suppressing messages and re-injecting 675 them at a later time is reduced by using timestamps. 677 The lack of accountability that comes with anonymity may have 678 implications for the security of a network. For example, many news 679 servers accept control messages automatically without any 680 cryptographic authentication. Possible countermeasures are discussed 681 in section 7. 683 9. Acknowledgments 685 Several people contributed ideas and source code to the Mixmaster v2 686 software. "Antonomasia" , Adam Back 687 and Bodo Moeller suggested 688 improvements to this document. 690 10. References 692 [Chaum 1981] Chaum, D., "Untraceable Electronic Mail, Return Addresses, and 693 Digital Pseudonyms", Communications of the ACM 24 (1981) 2. 695 [Mazieres 1998] Mazieres, D., and Kaashoek, F., "The Design, Implementation and 696 Operation of an Email Pseudonym Server", 697 5th ACM Conference on Computer and Communications Security, 1998. 698 . 700 [Moeller 1998] Moeller, U., "Anonymisierung von Internet-Diensten", 701 Studienarbeit, University of Hamburg, January 1998. 702 . 704 [RFC 822] Crocker, D., "Standard for the Format of ARPA Internet Text 705 Messages", STD 11, RFC 822, August 1982. 707 [RFC 1036] Horton, M., and Adams, R., "Standard for Interchange of 708 USENET Messages", RFC 1036, December 1987. 710 [RFC 1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 711 April 1992. 713 [RFC 1421] Linn, J., "Privacy Enhancement for Internet Electronic 714 Mail: Part I -- Message Encryption and Authentication Procedures", RFC 715 1421, February 1993. 717 [RFC 1952] Deutsch, P., "GZIP file format specification version 4.3", 718 RFC 1952, May 1996. 720 [RFC 2311] Dusse, S., Hoffman, P, Ramsdell, B, Lundblade, L., and 721 Repka, L., "S/MIME Version 2 Message Specification", RFC 2311, March 722 1998. 724 [RFC 2437] Kaliski, B., and Staddon, J., "PKCS #1: RSA Cryptography 725 Specifications, Version 2.0", RFC 2437, October 1998. 727 [RFC 2440] Callas, J., Donnerhacke, L., Finney, H., and Thayer, R.: 728 "OpenPGP Message Format", RFC 2440, November 1998. 730 [Schneier 1996] Schneier, B., "Applied Cryptography", 2nd Edition, Wiley, 731 1996. 733 11. Authors' Addresses 735 Ulf Moeller 737 EMail: mail@ulfm.de 739 Lance Cottrell 740 Anonymizer, Inc. 741 5694 Mission Center Road #426 742 San Diego, CA 92108-4380 744 EMail: loki@infonex.com 746 Peter Palfrader 748 EMail: peter@palfrader.org 750 Len Sassaman 751 Nomen Abditum Services 752 P.O. Box 99282 753 Emeryville, CA 94662-9282 755 EMail: rabbi@abditum.com