Although I haven't had time to think through the requirements in any
detail, I thought I'd throw out the following framework for discussing
requirements. Maybe Len can collect the feedback on these if he has the
time.
Rather than discussing the security requirements in the abstract, it may
be useful to discuss the capabilities/knowledge we want various parties
to possess -- this is a natural extension of threat modeling. The
following lists some of the parties of which I'm aware and the
capabilities I've heard expressed. A '+' means this must/can be allowed
(optionally, can't be prevented by the protocol), a '-' means this must
be prevented, and a '?' means I'm not sure there's consensus (we may
need other states as well).
Please add in the missing parties and capabilities.
Passive Network Attacker
+ know the source and destination remailers ip addresses and ports
- know the inter-remailer message contents
-? know the number of messages exchanged
? know the number of message blocks exchanged
- determine whether messages were accepted or rejected
- know the relative sizes of messages
Active Network Attacker (a superset of a passive attacker)
- impersonate the server
- truncate messages without detection
+ TCP-based DDoS
-? enumerate Key_IDs of receiving remailer's private keys
Corrupt Receiving Remailer
+ can throw away messages
+ can retain statistics
Corrupt Sending Remailer
+ must batch messages
+ can publish details of "stealth" remailers
Spammer
?
Sending Remailer
+ have local policies about retry rates and fallback
+ receive an unforgeable ephemeral receipt from receiving client
(without which the message is assumed undelivered and given which
the receiving remailer queues for further delivery)
Receiving Remailer
+ can accept messages on the inter-remailer protocol only (not SMTP)
+ can exist without publication
+ can require sending remailers to authenticate
User
+ can specify a stealth remailer as a middle hop, including port number
Ok, that's all I have off the top of my head. Now everyone else can
take their whacks...
cheers,
--Scott
--
Scott Renfro <scott@...>
|