idnits 2.17.1 draft-sassaman-mixmaster-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 887. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 864. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 871. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 877. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (December 29, 2004) is 7059 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'RFC 1952' on line 295 == Unused Reference: '11' is defined on line 802, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 806, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' ** Obsolete normative reference: RFC 1036 (ref. '8') (Obsoleted by RFC 5536, RFC 5537) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '9') ** Downref: Normative reference to an Historic RFC: RFC 1421 (ref. '10') ** Downref: Normative reference to an Informational RFC: RFC 1952 (ref. '11') ** Downref: Normative reference to an Historic RFC: RFC 2311 (ref. '12') ** Obsolete normative reference: RFC 2437 (ref. '13') (Obsoleted by RFC 3447) ** Obsolete normative reference: RFC 2440 (ref. '14') (Obsoleted by RFC 4880) ** Obsolete normative reference: RFC 2487 (ref. '15') (Obsoleted by RFC 3207) ** Obsolete normative reference: RFC 2822 (ref. '16') (Obsoleted by RFC 5322) Summary: 16 errors (**), 0 flaws (~~), 4 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group U. Moeller 3 Internet-Draft Secardeo GmbH 4 Expires: June 29, 2005 L. Cottrell 5 Anonymizer, Inc. 6 P. Palfrader 7 The Mixmaster Project 8 L. Sassaman 9 Nomen Abditum Services 10 December 29, 2004 12 Mixmaster Protocol Version 2 13 draft-sassaman-mixmaster-03.txt 15 Status of this Memo 17 This document is an Internet-Draft and is subject to all provisions 18 of section 3 of RFC 3667. By submitting this Internet-Draft, each 19 author represents that any applicable patent or other IPR claims of 20 which he or she is aware have been or will be disclosed, and any of 21 which he or she become aware will be disclosed, in accordance with 22 RFC 3668. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as 27 Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on June 29, 2005. 42 Copyright Notice 44 Copyright (C) The Internet Society (2004). 46 Abstract 48 Most e-mail security protocols only protect the message body, leaving 49 useful information such as the identities of the conversing parties, 50 sizes of messages and frequency of message exchange open to 51 adversaries. This document describes Mixmaster version 2, a mail 52 transfer protocol designed to protect electronic mail against traffic 53 analysis. 55 Mixmaster is based on David Chaum's mix-net concept. A mix 56 (remailer) is a service that forwards messages, using public key 57 cryptography to hide the correlation between its inputs and outputs. 58 Sending messages through sequences of remailers achieves anonymity 59 and unobservability of communications against a powerful adversary. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. The Mix-Net Protocol . . . . . . . . . . . . . . . . . . . . . 3 65 2.1 Message Creation . . . . . . . . . . . . . . . . . . . . . 3 66 2.2 Remailing . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2.3 Message Reassembly . . . . . . . . . . . . . . . . . . . . 5 68 3. Pool Behavior . . . . . . . . . . . . . . . . . . . . . . . . 5 69 3.1 Timed Dynamic Pool Mix Algorithm . . . . . . . . . . . . . 5 70 3.2 Dummy Traffic . . . . . . . . . . . . . . . . . . . . . . 6 71 4. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 6 72 4.1 Payload Format . . . . . . . . . . . . . . . . . . . . . . 6 73 4.2 Cryptographic Algorithms . . . . . . . . . . . . . . . . . 7 74 4.3 Packet Format . . . . . . . . . . . . . . . . . . . . . . 7 75 4.3.1 Header Section Format . . . . . . . . . . . . . . . . 8 76 4.3.2 Body Format . . . . . . . . . . . . . . . . . . . . . 10 77 4.4 Mail Transport Encoding . . . . . . . . . . . . . . . . . 10 78 5. Key Format . . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 6. Implementation Notes . . . . . . . . . . . . . . . . . . . . . 12 80 6.1 Remixing . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 6.2 Administrative Commands . . . . . . . . . . . . . . . . . 13 82 6.3 Dummy Traffic . . . . . . . . . . . . . . . . . . . . . . 13 83 6.4 Key Rotation . . . . . . . . . . . . . . . . . . . . . . . 13 84 6.5 Delivery of Anonymous Messages . . . . . . . . . . . . . . 14 85 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 86 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 87 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18 89 Intellectual Property and Copyright Statements . . . . . . . . 20 91 1. Introduction 93 This document describes a mail transfer protocol designed to protect 94 electronic mail against traffic analysis. Most e-mail security 95 protocols only protect the message body, leaving useful information 96 such as the identities of the conversing parties, sizes of messages 97 and frequency of message exchange open to adversaries. 99 Message transmission can be protected against traffic analysis by the 100 mix-net protocol. A mix (remailer) is a service that forwards 101 messages, using public key cryptography to hide the correlation 102 between its inputs and outputs. If a message is sent through a 103 sequence of mixes, one trusted mix is sufficient to provide anonymity 104 and unobservability of communications against a powerful adversary. 105 Mixmaster is a mix-net implementation for electronic mail. 107 This memo describes version 2 of the Mixmaster message format, as 108 used on the Internet since 1995. 110 2. The Mix-Net Protocol 112 The mix-net protocol [1] allows one to send messages while hiding the 113 relation of sender and recipient from observers (unobservability). 114 It also allows the sender of a message to remain anonymous to the 115 recipient (sender anonymity). If anonymity is not desired, 116 authenticity and unobservability can be achieved at the same time by 117 transmitting digitally signed messages. 119 This section gives an overview of the protocol and messaging pattern. 120 The mixing algorithm is specified in Section 3, and the message 121 format is specified in Section 4. 123 Viewed from a high level, Mixmaster is like a packet network, where 124 each node in the network is known as a "remailer." The original 125 content is split into pieces, and an independent path is determined 126 for each piece, with the only requirement that all paths must end at 127 the same remailer. Each piece is multiply encrypted so that any 128 intermediate remailer can only decrypt enough information to 129 determine the next hop in the path. When all pieces have arrived at 130 the final remailer, the original content is re-created and sent to 131 its final destination. 133 2.1 Message Creation 135 In this section the terms "sender" and "user agent" are used 136 informally. 138 The user agent splits the original content into chunks of 10236 139 bytes; if the last chunk is shorter, random padding is added. Each 140 chunk has a four-byte length prepended, and the result is called the 141 packet body. If sender anonymity is desired, care should be taken to 142 not include any identifying information (such as headers or unique 143 content from the original plaintext message) in the packets. The 144 content may be compressed before splitting. 146 The sender next chooses a chain of up to 20 remailers for each 147 packet. Each path is independent, and can be of a different length, 148 but all paths must end at the same remailer. This final remailer is 149 responsible for detecting and discarding duplicate packets, 150 reconstructing the message, and doing the final delivery. 152 Each packet is next prepared as follows (the full details are in 153 Section 4.3.1). For a chain of "n" remailers, headers "n + 1" 154 through 20 are filled with random data. For headers "n" down to one, 155 the sender generates a symmetric encryption key. This key is used to 156 encrypt the packet body and all the following headers. The key, and 157 other control information, is then encrypted with the public key of 158 the "n"'th remailer in the chain. 160 The process is repeated, working backward through the chain until the 161 first packet has header information encrypted for the first remailer, 162 and the packet body has been encrypted "n" times. The packet is then 163 sent to the first remailer on its chain. 165 2.2 Remailing 167 When a remailer receives a message, it uses its private key to 168 decrypt the first header section. The Packet ID (see Section 4.3.1) 169 can be used to detect duplicates. The integrity of the message is 170 verified by checking the packet length and verifying the message 171 digest in the packet header. 173 All header sections, as well as the packet body, are decrypted with 174 the symmetric key found in the header. This reveals a public 175 key-encrypted header section for the next remailer. 177 The first header section is now removed, the others are shifted up, 178 and the last section is replaced with random bytes. Transport 179 encoding is applied to the new message as described in Section 4.4. 181 In order to prevent an adversary from determining the relationship 182 between incoming and outgoing messages (i.e., traffic analysis), the 183 remailer must collect several encrypted messages before sending the 184 message it has just created; see Section 3.1. 186 2.3 Message Reassembly 188 When a packet is sent to the final remailer, it contains an 189 indication that the chain ends at that remailer, and whether the 190 packet contains the complete message or if it is part of a multi-part 191 message. If the packet contains the entire message, the packet body 192 is decrypted and after reordering messages, the plain text is 193 delivered to the recipient. For partial messages, a message ID is 194 used to identify the other parts as they arrive. When all parts have 195 arrived, the message is reassembled, decompressed if necessary, and 196 delivered. A final remailer may discard partial messages if all 197 packets have not been received within a local time limit. 199 Note that only the final remailer can determine whether packets are 200 part of a specific message. To all of other remailers, the packets 201 appear to be completely independent. 203 3. Pool Behavior 205 3.1 Timed Dynamic Pool Mix Algorithm 207 To obfuscate the link between incoming and outgoing messages, 208 Mixmaster uses a pooling scheme. Messages to be forwarded are stored 209 in a pool. At regular intervals the remailer sends some random 210 messages from the pool to either the next hop or their final 211 recipients. 213 The pooling scheme is a "Timed Dynamic Pool Mix" [6], which has the 214 following three parameters: 216 +--------------+----------------------------------------------------+ 217 | Name | Description | 218 +--------------+----------------------------------------------------+ 219 | t | Mixing interval | 220 | min | Minimum number of messages in the pool | 221 | rate | Percentage of messages to be send in one round | 222 +--------------+----------------------------------------------------+ 224 The following steps are implemented every "t" seconds: 225 1. Let "n" be the number of messages currently in the pool. 226 2. Let "count" be the smaller of "n - min" and "n * rate", or zero 227 if "n - min" is negative. 228 3. Select "count" messages from the pool at random and send them. 230 In its default configuration, Mixmaster has a mixing interval of 15 231 minutes, a minimum pool size of 45 messages, and permits a maximum of 232 65% of the pool to be sent in one round. 234 3.2 Dummy Traffic 236 Dummy messages (see Section 4.1) are multi-hop messages with four 237 randomly selected remailers as the chain. The chain must be selected 238 such that no remailer will appear twice unless two other remailers 239 separate them. 241 Every time a message is placed in the pool, the remailer chooses a 242 random number from a geometric distribution and creates that many 243 dummy messages which are also placed in the pool. 245 Similarly, prior to each execution of the mixing algorithm described 246 in Section 3.1, the remailer selects a random number from a different 247 geometric distribution and adds that many dummy messages to the pool 248 as well. 250 The parameters should be chosen so that on average the remailer 251 creates one dummy for every 32 inbound messages and one every nine 252 mixing rounds. 254 4. Message Format 256 4.1 Payload Format 258 The message payload can be an e-mail message [16], a Usenet message 259 [8], or a dummy message. 261 Mail and Usenet messages are prefixed with data specifying the 262 payload type. An additional, more restricted method of specifying 263 message header lines is defined for reasons of backward 264 compatibility. 266 The payload format is as follows: 268 Number of destination fields [ 1 byte] 269 Destination fields [ 80 bytes each] 270 Number of header line fields [ 1 byte] 271 Header lines fields [ 80 bytes each] 272 User data section [ 2549K - previous fields ] 274 Each destination field consists of a string of up to 80 ASCII 275 characters, padded with null-bytes to a total size of 80 bytes. The 276 following strings are defined: 277 null: Dummy message. The remailer will discard the message. 278 post: Usenet message. The remailer will post the message to Usenet. 280 post: [newsgroup] Usenet message. The remailer will add a 281 "Newsgroups" header with the specified content, and post the 282 message to Usenet. 283 [address] E-mail message. The remailer will add a "To" header with 284 the specified content, and send the message as e-mail. 286 If no destination field is given, the payload is an e-mail message. 288 Message headers can be specified in header line fields. Each header 289 line field consists of a string of up to 80 ASCII characters, padded 290 with null-bytes to a total size of 80 bytes. 292 There are three types of user data sections: 293 o A compressed user data section begins with the GZIP identification 294 header (31, 139). This header contains an additional user data 295 section. The data are compressed using GZIP [RFC 1952]. The GZIP 296 operating system field must be set to Unix, and file names must 297 not be given. Compression may be used if the capabilities 298 attribute of the final remailer contains the flag "C". 299 o An RFC 2822 user data section begins with the three bytes "##[CR]" 300 (35, 35, 13). It contains an e-mail message or a Usenet message. 301 o A user data section not beginning with one of the above 302 identification strings contains only the body of the message. 303 When this type of user data section is used, the message header 304 fields must be included in destination and header line fields. 306 The payload is limited to a maximum size of 2610180 bytes. 307 Individual 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 311 policy; see Section 5. 313 4.2 Cryptographic Algorithms 315 The asymmetric encryption mechanism is RSA with 1024 bit RSA keys and 316 the PKCS #1 v1.5 (RSAES-PKCS1-v1_5) padding format [13]. The 317 symmetric encryption mechanism is EDE 3DES with cipher block chaining 318 (24-byte key, 8-byte initialization vector) [7]. MD5 [9] is used as 319 the message digest algorithm. 321 4.3 Packet Format 323 A Mixmaster packet consists of a header containing information for 324 the remailers, and a body containing payload data. To ensure that 325 packets are indistinguishable, the fields are all of fixed size. 327 The packet header consists of 20 header sections (specified in 328 Section 4.3.1) of 512 bytes each, resulting in a total header size of 329 10240 bytes. The header sections (except for the first one) and the 330 packet body are encrypted with symmetric session keys specified in 331 the first header section. 333 +-------------------+ 334 | Header section 1 | 335 +- - - - - - - - - -+ 336 | Header section 2 | 337 +- - - - - - - - - -+ 338 + ... + 339 +- - - - - - - - - -+ 340 | Header section 20 | 341 +-------------------+ 342 | | 343 | Payload | 344 | | 345 | | 346 | | 347 | | 348 | | 349 +-------------------+ 351 4.3.1 Header Section Format 353 Packet layout 355 [ Public key ID 16 bytes ] 356 [ Length of RSA-encrypted data 1 byte ] 357 [ RSA-encrypted session key 128 bytes ] 358 [ Initialization vector 8 bytes ] 359 [ Encrypted header part 328 bytes ] 360 [ Random padding 31 bytes ] 361 Total size: 512 bytes 363 To generate the RSA-encrypted session key, a 24-byte Triple-DES key 364 is encrypted with RSAES-PKCS1-v1_5, resulting in 128 bytes (1024 365 bits) of encrypted data. This Triple-DES key and the initialization 366 vector provided in clear are used to decrypt the encrypted header 367 part. They are not used at other stages of message processing. 369 The 328 bytes of data encrypted to form the encrypted header part are 370 as follows: 372 [ Packet ID 16 bytes ] 373 [ Triple-DES key 24 bytes ] 374 [ Packet type identifier 1 byte ] 375 [ Packet information depends on packet type ] 376 [ Timestamp 7 bytes ] 377 [ Message digest 16 bytes ] 378 [ Random padding as needed ] 379 Total size: 328 bytes 381 The fields are defined as follows: 382 Packet ID: randomly generated packet identifier. 383 Triple-DES key: used to encrypt the following header sections and the 384 packet body. 385 Packet type identifier: The type identifiers are: 387 +--------------+----------------------------------------------------+ 388 | Value | Type | 389 +--------------+----------------------------------------------------+ 390 | 0 | Intermediate hop | 391 | 1 | Final hop, complete message | 392 | 2 | Final hop, partial message | 393 +--------------+----------------------------------------------------+ 395 Timestamp: A timestamp is introduced with the byte sequence (48, 48, 396 48, 48, 0). The following two bytes specify the number of days 397 since January 1, 1970 (00:00 UTC), in little-endian byte order. A 398 random number between one and three, inclusive, may be subtracted 399 from the number of days in order to obscure the origin of the 400 message. 401 Message digest: MD5 digest computed over the preceding elements of 402 the encrypted header part. 404 The packet information depends on the packet type identifier, as 405 follows: 407 Packet type 0 (intermediate hop): 408 [ 19 Initialization vectors 152 bytes ] 409 [ Remailer address 80 bytes ] 411 Packet type 1 (final hop): 412 [ Message ID 16 bytes ] 413 [ Initialization vector 8 bytes ] 415 Packet type 2 (final hop, partial message): 416 [ Chunk number 1 byte ] 417 [ Number of chunks 1 byte ] 418 [ Message ID 16 bytes ] 419 [ Initialization vector 8 bytes ] 421 Initialization vectors: For packet type 1 and 2, the IV is used to 422 symmetrically encrypt the packet body. For packet type 0, there 423 is one IV for each of the 19 following header sections. The IV 424 for the last header section is also used for the packet body. 425 Remailer address: E-mail address of next hop. 426 Message ID: Identifier unique to (all chunks of) this message. 427 Chunk number: Sequence number used in multi-part messages, starting 428 with one. 429 Number of chunks: Total number of chunks. 431 In the case of packet type zero, header sections two through twenty, 432 and the packet body, each are decrypted separately using the 433 respective initialization vectors. In the case of packet types one 434 and two, header sections two through twenty are ignored, and the 435 packet body is decrypted using the given initialization vector. 437 4.3.2 Body Format 439 The message payload Section 4.1 is split into chunks of 10236 bytes. 440 Random padding is added to the last chunk if necessary. The length 441 of each chunk (not counting the padding), is prepended to the chunk 442 as a four-byte little-endian number. This forms the body of a 443 Mixmaster packet. 445 A message may consist of up to 255 packets. 447 4.4 Mail Transport Encoding 449 Mixmaster packets are sent as standard email messages [16]. The 450 message body has the following format: 452 ## 453 Remailer-Type: Mixmaster [version number] 455 -----BEGIN REMAILER MESSAGE----- 456 [packet length ] 457 [message digest] 458 [encoded packet] 459 -----END REMAILER MESSAGE----- 461 The length field always contains the decimal number "20480", since 462 the size of Mixmaster packets is constant. An MD5 message digest [9] 463 of the packet prior to Base-64 encoding is encoded in Base-64. 465 The packet itself is encoded in Base-64 encoding [10], with 466 line-breaks every 40 characters. 468 5. Key Format 470 Remailer public key files consist of a list of attributes and a 471 public RSA key: 473 [attributes list] 475 -----Begin Mix Key----- 476 [key ID] 477 [length] 478 [encoded key] 479 -----End Mix Key----- 481 The attributes are listed in one line separated by spaces. 482 Individual attributes must not contain whitespace, and are defined as 483 follows: 485 identifier: A human readable string identifying the remailer 486 address: The remailer's Internet mail address 487 key ID: Public key ID 488 version: Software version number 489 capabilities: Flags indicating additional remailer capabilities 490 validity date: Date from which the key is valid 491 expiration date: Date of the key's expiration 493 The identifier consists of lowercase alphanumeric characters, 494 beginning with an alphabetic character. The identifier should be no 495 more than eight characters in length. 497 The key ID is the MD5 message digest of the representation of the RSA 498 public key (not including the length bytes). It is encoded as a 499 hexadecimal string. 501 The version field consists of the protocol version number followed by 502 a colon and the software version information, limited to the ASCII 503 alphanumeric characters, plus dot (.) and dash (-). All 504 implementations of the protocol specified here should prepend the 505 software version with "2:". Existing implementations lacking a 506 protocol version number imply protocol version 2. 508 The capabilities field is optional. It is a list of flags 509 represented by a string of ASCII characters. Clients should ignore 510 unknown flags. The following flags are defined: 512 +--------------+----------------------------------------------------+ 513 | Flag | Meaning | 514 +--------------+----------------------------------------------------+ 515 | C | Accepts compressed messages | 516 | M | Will forward messages to another mix when used as | 517 | | final hop | 518 | Nm | Supports posting to Usenet through a mail-to-news | 519 | | gateway | 520 | Np | Supports direct posting to Usenet | 521 +--------------+----------------------------------------------------+ 523 The date fields are optional. They are ASCII date stamps in the 524 format YYYY-MM-DD. The first date indicates the date from which the 525 key is first valid; the second date indicates its expiration. If 526 only one date is present, it is treated as the key creation date. 527 (The date stamp implies 00:00 UTC). 529 The version, capabilities, and date fields must each be no longer 530 than 125 characters. 532 The encoded key part consists of two bytes specifying the key length 533 (1024 bits) in little-endian byte order, and of the RSA modulus and 534 the public exponent in big-endian form using 128 bytes each, with 535 preceding null bytes for the exponent if necessary. The packet is 536 encoded in Base-64 [10], with line-breaks every 40 characters. Its 537 length (258 bytes) is given as a decimal number. 539 Digital signatures [14] should be used to ensure the authenticity of 540 the key files. 542 6. Implementation Notes 544 This section discusses various implementation issues. 546 6.1 Remixing 548 Some remailers may understand multiple remailer protocols. In the 549 interest of creating a unified anonymity set, remailers which speak 550 multiple remailer protocols should attempt to remix messages that use 551 the older protocols whenever possible. 553 When a remailer receives a message in the older protocol format, it 554 should determine if the message destination is another remailer which 555 also speaks the Mixmaster protocol. If the remailer knows the 556 Mixmaster public key for the next hop, it should process the message 557 normally, but instead of sending the message to its next hop, treat 558 the processed message as opaque data which will comprise the body of 559 a Mixmaster message. The remailer should then create a Mixmaster 560 message with this body to be delivered to the next hop remailer. 562 Ensuring that a remailer's keyring contains up to date copies of the 563 public keys for other remailers is the responsibility of the given 564 remailer's operator. Utilities such as Echolot [2] can be used to 565 assist in automating this task. 567 If the remailer receives a Mixmaster message that, when decrypted, 568 contains a message in an alternate protocol supported by the 569 remailer, it should process the message as though it had initially 570 been delivered in the alternate protocol format. 572 6.2 Administrative Commands 574 The existing remailer software understands a number of specific 575 administrative commands. These commands are sent via the Subject: 576 line of an e-mail to the email address of the remailer: 577 remailer-help: Returns information about using the remailer. The 578 remailer may support a suffix consisting of a dash and a 579 two-letter ISO 639 country code. For example, remailer-help-ar 580 will return a help file in Arabic, if available. Supported 581 languages should be listed at the beginning of the "remailer-help" 582 response. 583 remailer-key: Returns the remailer's public key as described in 584 Section 5. It may also return the keys and attributes of other 585 remailers it knows about. 586 remailer-stats: Returns information about the number of messages the 587 remailer has processed per day (again, a day starts at 00:00 UTC). 588 remailer-conf: Returns local configuration information such as 589 software version, supported protocols, filtered headers, blocked 590 newsgroups and domains, and the attribute strings for other 591 remailers the remailer knows about. 592 remailer-adminkey: Returns the OpenPGP [14] key of the remailer's 593 operator. 595 6.3 Dummy Traffic 597 Older versions of Mixmaster (2.0.4 through 2.9.0) allowed for the 598 creation of dummy message cover traffic, but provided no automated 599 means for introducing this dummy traffic into the system. Beginning 600 in version 3.0, Mixmaster employs an internal dummy policy. 602 6.4 Key Rotation 604 Beginning with version 3.0, Mixmaster offers automatic key rotation. 605 Care must be taken to minimize the possibility for partitioning 606 attacks during the key rotation window. 608 Keys are generated with a validity date and an expiration date. User 609 agents should only display valid keys which have not expired. 611 Keys are valid for a 13 month period. A remailer must generate a new 612 key when the existing key's expiration date is one month or less in 613 the future. When queried, a remailer must report the most recently 614 generated key as its key, effectively giving each key a 12 month 615 service period. 617 Remailers must continue to decrypt and process mail encrypted to 618 expired keys for one week past the expiration date on the key. One 619 week after expiration, an expired remailer key should be securely 620 destroyed. 622 6.5 Delivery of Anonymous Messages 624 When anonymous messages are forwarded to third parties, remailer 625 operators should be aware that senders might try to supply header 626 fields that indicate a false identity or to send unauthorized Usenet 627 control messages. This is a problem because many news servers accept 628 control messages automatically without any authentication. 630 For these reasons, remailer software should allow the operator to 631 disable certain types of message headers, and to insert headers 632 automatically. 634 Remailers usually add a "From:" field containing an address 635 controlled by the remailer operator to anonymous messages. Using the 636 word "Anonymous" in the name field allows recipients to apply scoring 637 mechanisms and filters to anonymous messages. Appropriate additional 638 information about the origin of the message can be inserted in the 639 "Comments:" header field of the anonymous messages. 641 Anonymous remailers are sometimes used to send harassing e-mail. To 642 prevent this abuse, remailer software should allow operators to block 643 destination addresses on request. Real-life abuse and attacks on 644 anonymous remailers are discussed in [3]. 646 7. Security Considerations 648 The security of the mix-net relies on the assumption that the 649 underlying cryptographic primitives are secure. In addition, 650 specific attacks on the mix-net need to be considered; [5] contains a 651 more detailed analysis of these attacks. 653 Passive adversaries can observe some or all of the messages sent to 654 mixes. The users' anonymity comes from the fact that a large number 655 of messages are collected and sent in random order. For that reason 656 remailers should collect as many messages as possible while keeping 657 the delay acceptable. 659 Statistical traffic analysis is possible even if single messages are 660 anonymized in a perfectly secure way: an eavesdropper may correlate 661 the times of Mixmaster packets being sent and anonymized messages 662 being received. This is a powerful attack if several anonymous 663 messages can be linked together (by their contents or because they 664 are sent under a pseudonym). To protect themselves, senders must 665 mail Mixmaster packets stochastically independent of the actual 666 messages they want to send. This can be done by sending packets at 667 regular intervals, using a dummy message whenever appropriate. To 668 avoid leaking information, the intervals should not be smaller than 669 the randomness in the delay caused by trusted remailers. 671 There is no anonymity if all remailers in a given chain collude with 672 the adversary, or if they are compromised during the lifetime of 673 their keys. Using a longer chain increases the assurance that the 674 user's privacy will be preserved, but at the same time causes lower 675 reliability and higher latency. Sending redundant copies of a 676 message increases reliability but may also facilitate attacks. An 677 optimum must be found according to the individual security needs and 678 trust in the remailers. 680 Active adversaries can also create, suppress or modify messages. 681 Remailers must check the packet IDs to prevent replay attacks. To 682 minimize the number of packet IDs that the remailer must retain, 683 packets which bear a timestamp more than a reasonable number of days 684 in the past may be discarded. Implementors should consider that 685 packets maybe up to three days younger than indicated by the 686 timestamp, and select an expiration value which allows sufficient 687 time for legitimate messages to pass through the network. The number 688 of packet IDs that the remailer must retain can be further minimized 689 by discarding packet IDs for packets encrypted to a key which has 690 expired more than a week in the past. 692 The use of a link-level encryption protocol with an ephemeral key, 693 such as STARTTLS with SMTP [15], provides for forward secrecy and 694 further aids against replay attacks. Remailer operators should be 695 encouraged to deploy such solutions at the MTA level whenever 696 possible. 698 Early implementations of Mixmaster did not generate a timestamp 699 packet. Implementors should be aware of the partitioning attack 700 implications if they chose to permit processing of packets without 701 timestamps. Mixmaster versions 2.0.5 and greater in the 2.0.x tree 702 as well as Mixmaster 3.0 in the 3.x tree do not permit processing of 703 such packets. 705 Message integrity must be verified to prevent the adversary from 706 performing chosen ciphertext attacks or replay attacks with modified 707 packet IDs, and from encoding information in an intercepted message 708 in a way not affected by decryption (e.g. by modifying the message 709 length or inducing errors). This version of the protocol does not 710 provide integrity for the packet body. Because the padding for 711 header section is random, in this version of the protocol it is 712 impossible for a remailer to check the integrity of the encrypted 713 header sections that will be decrypted by the following remailers. 714 Chosen ciphertext attacks and replay attacks are detected by 715 verifying the message digest included in the header section. 717 The adversary can trace a message if he knows the decryption of all 718 other messages that pass through the remailer at the same time. To 719 make it less practical for an attacker to flood a mix with known 720 messages, remailers can store received messages in a reordering pool 721 that grows in size while more than average messages are received, and 722 periodically choose at random a fixed fraction of the messages in the 723 pool for processing. There is no complete protection against 724 flooding attacks in an open system, but if the number of messages 725 required is high, an attack is less likely to go unnoticed. 726 Additional work has been done in the field of active flooding attack 727 protection; future mix-net protocols may wish to take advantage of 728 this work [4]. 730 If the adversary suppresses all Mixmaster messages from one 731 particular sender and observes that anonymous messages of a certain 732 kind are discontinued at the same time, that sender's anonymity is 733 compromised with high probability. There is no practical 734 cryptographic protection against this attack in large-scale networks. 735 The effect of a more powerful attack that combines suppressing 736 messages and re-injecting them at a later time is reduced by using 737 timestamps. 739 Manipulation of the distribution of remailer keys, capabilities, and 740 statistics can lead to powerful attacks against a remailer network. 741 Sensitive information such as this should be distributed in a secure 742 manner. 744 The lack of accountability that comes with anonymity may have 745 implications for the security of a network. For example, many news 746 servers accept control messages automatically without any 747 cryptographic authentication. Possible countermeasures are discussed 748 in Section 6.5. 750 8. Acknowledgments 752 Several people contributed ideas and source code to the Mixmaster v2 753 software. 755 "Antonomasia" , Adam Back , 756 Marco A. Calamari , Colin Tuckley 757 , Bodo Moeller , and Jon Orbeton 758 suggested improvements to this document. 759 Rich Salz contributed significantly to this 760 document by XMLifying it and rewording many ambiguous sections. 761 Myles Conley also reworded many ambiguous 762 sections and contributed important suggestions for improving clarity. 764 9 References 766 [1] Chaum, D., "Untraceable Electronic Mail, Return Addresses, and 767 Digital Pseudonyms", Communications of the ACM 24:2, 1981. 769 [2] Palfrader, P., "Echolot: A Pinger for Anonymous Remailers", 770 2003, . 772 [3] Mazieres, D. and F. Kaashoek, "The Design, Implementation and 773 Operation of an Email Pseudonym Server", 1998, 774 . 776 [4] Danezis, G. and L. Sassaman, "Heartbeat Traffic to Counter 777 (n-1) Attacks", October 2003, 778 . 780 [5] Moeller, U., "Anonymisierung von Internet-Diensten", January 781 1998, 782 . 785 [6] Serjantov, A., Dingledine, R. and P. Syverson, "From a Trickle 786 to a Flood: Active Attacks on Several Mix Types", October 2002, 787 . 789 [7] Menezes, A., van Oorschot, P. and S. Vanstone, "Handbook of 790 Applied Cryptography", CRC Press, 1996. 792 [8] Horton, M. and R. Adams, "Standard for interchange of USENET 793 messages", RFC 1036, December 1987. 795 [9] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 796 1992. 798 [10] Linn, J., "Privacy Enhancement for Internet Electronic Mail: 799 Part I: Message Encryption and Authentication Procedures", RFC 800 1421, February 1993. 802 [11] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L. and G. 803 Randers-Pehrson, "GZIP file format specification version 4.3", 804 RFC 1952, May 1996. 806 [12] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L. and L. 807 Repka, "S/MIME Version 2 Message Specification", RFC 2311, 808 March 1998. 810 [13] Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography 811 Specifications Version 2.0", RFC 2437, October 1998. 813 [14] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP 814 Message Format", RFC 2440, November 1998. 816 [15] Hoffman, P., "SMTP Service Extension for Secure SMTP over TLS", 817 RFC 2487, January 1999. 819 [16] Resnick, P., "Internet Message Format", RFC 2822, April 2001. 821 Authors' Addresses 823 Ulf Moeller 824 Secardeo GmbH 825 Betastr. 9a 826 85774 Unterfoehring 827 Germany 829 EMail: ulf.moeller@secardeo.com 831 Lance Cottrell 832 Anonymizer, Inc. 833 5694 Mission Center Road #426 834 San Diego, CA 92108-4380 835 USA 837 EMail: loki@infonex.com 839 Peter Palfrader 840 The Mixmaster Project 841 Hoettinger Auffahrt 1 842 6020 Innsbruck 843 Austria 845 EMail: peter@palfrader.org 846 URI: http://www.palfrader.org/ 847 Len Sassaman 848 Nomen Abditum Services 849 P.O. Box 900481 850 San Diego, CA 92190-0481 851 USA 853 EMail: rabbi@abditum.com 855 Intellectual Property Statement 857 The IETF takes no position regarding the validity or scope of any 858 Intellectual Property Rights or other rights that might be claimed to 859 pertain to the implementation or use of the technology described in 860 this document or the extent to which any license under such rights 861 might or might not be available; nor does it represent that it has 862 made any independent effort to identify any such rights. Information 863 on the procedures with respect to rights in RFC documents can be 864 found in BCP 78 and BCP 79. 866 Copies of IPR disclosures made to the IETF Secretariat and any 867 assurances of licenses to be made available, or the result of an 868 attempt made to obtain a general license or permission for the use of 869 such proprietary rights by implementers or users of this 870 specification can be obtained from the IETF on-line IPR repository at 871 http://www.ietf.org/ipr. 873 The IETF invites any interested party to bring to its attention any 874 copyrights, patents or patent applications, or other proprietary 875 rights that may cover technology that may be required to implement 876 this standard. Please address the information to the IETF at 877 ietf-ipr@ietf.org. 879 Disclaimer of Validity 881 This document and the information contained herein are provided on an 882 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 883 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 884 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 885 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 886 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 887 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 889 Copyright Statement 891 Copyright (C) The Internet Society (2004). This document is subject 892 to the rights, licenses and restrictions contained in BCP 78, and 893 except as set forth therein, the authors retain all their rights. 895 Acknowledgment 897 Funding for the RFC Editor function is currently provided by the 898 Internet Society.