Re: Lurkers: First draft: call for comments (was Re: Paper deadlines)

[Len Sassaman <rabbi@quickie.net>]

On Sun, 5 May 2002, Roger Dingledine wrote:

> We now have a 'reasonably complete' draft. If you've been lurking on the

Section 2.3 should read "The Jack B Nymble 2 remailer client and the
Mixmaster 2.9 remailer software allow [...]"

In section 3, where it says "We choose to drop backward-compatibility
with Mixmaster", do we want to include information on remixing so as to
clarify the ease of transition? Perhaps add the following paragraph:

Minimal backwards compatibility can be obtained through the use of
"remixing" Type II messages to be Type III messages, thus increasing the
anonymity set of the Type III remailers. Type II messages, when received
by a remailer capable of understanding both Type II and III and destined
for a remailer capable of understanding both Type II and III, are treated
as plaintext and encrypted to the next remailer in the chain using its
Type III key. The message is then sent as Type III encrypted message, and
decrypted to reveal the Type II message.

[...]

On the link-level encryption section, it also gets us the ability to have
true "middleman remailers".

Also, having the receiving remailer sign the EDH key is somewhat
unnecessary, since it can't decrypt the payload anyway if it isn't the
real server. (Though there could be some DOS attack prevention here.)

How about

4.1 Link-level encyption and what it gets us

   Unlike remailer Types I and II that used SMTP [29] (i.e. ordinary
Internet e-mail) as their underlying transport mechanism, Mixminion
clients and nodes communicate using a forward secure encrypted channel
based on TLS [12]. TLS allows the establishment of an encrypted tunnel
using ephemeral Diffie-Hellman keys. As soon as the session key has been
established, the parties destroy their Diffie-Hellman keys and begin
sending messages through the tunnel. After each message, the parties
perform a standard key update operation to generate a fresh key, and
delete the old key material.  Key updats don't require any asymmetric
encryption techniques, so they are relatively fast.
   In order to verify that the sending node is a remailer known to the
receiving node, the sending node can sign the ephemeral key. This allows
certain nodes to operate as "middleman remailers", which only accept
messages from or deliver messages to other remailers (See section 4.3). In
order to guarantee that the receiving node is the one intended by the
creator of the anonymous message, the receiving node can also sign the
ephermeral key.  This protects against data loss caused by remailer node
impersonation attacks, but is unnecessary for the anonymity of the
message.
   The above scheme [...]


[...]

Should we add mention of remixing to 4.2? What about explicit mention of
link-level requirements (i.e., demands signing, etc.)?

Hmm.

Keeping hashes of all the headers received since the last key rotation
will cause the same problems as keeping an incredibly long id.log -- the
search time for the will damage performance of the system. We're looking
at moving id.log to a db hash presently. Should potential performance
problems be noted?


--Len.