Re: Notes from Conversation with Roger

[George Danezis <gd@theory.lcs.mit.edu>]

Dear All,

Some comments on the discussion. Where I do not comment I silently agree 
or have no strong opinion.

On 21 Mar 2002, Nick Mathewson wrote:
> NOT ALL OF THESE OBSERVATIONS ARE TRUE.  This was all brainstorming. 
> 
> - Although we have said we don't want to log individual messages, it
>   appears that some operators would like usage statistics.  Perhaps
>   it would be good to tabulate number of incoming messages vs. number 
>   of messages sent via each output method.
> 

I agree. At the end of the day it is the only of assessing the size of 
anonymity sets and latency. Aggregate information should not be rich 
enough to reduce the anonymity sets.

> ABUSE
> 
>     - Abuse seems to be the biggest unaddressed problem for people who 
>       run remailers.
> 
>      - Curtailing bandwidth is desirable, but won't get abuse complaints
>        to go away: somebody can send a threatening message in under 1k.
> 

<political content> 
I think the best response to this is that you cannot 
make technology impossible to abuse. Particularly when abuse is 
such an ill defined term. Someone who want to send a 
threatening message of less than 1k can print it on a piece of paper leave 
it on someone's door or even post it. Its funny that they are still looking 
for the guy (or girl) who was sending the anthraxed mail! 
So what we should emphasize is that MixMinion is not the weakest link in 
the world, and if you really want to send threatening messages you can do 
it with less hassle in other ways.
</political content>

>      OBSERVATION 1: It's okay if there are different output methods
>      for nodes that accept different levels of exposure to abuse 
>      complaints.  Even if there are never more than a couple dozen nodes
>      willing to send SMTP to all and sundry, they could be supplanted by
>      others that send SMTP to those who opt in, others that encrypt and 
>      store...

I think we should stick with the idea that MixMinion is a generic 
transport mechanism and people can provide any service they want on top, 
and it is up to them to filter their interactions with the outside world.
Of course we should implement a service (and Mail seems a good one) to 
illustrate MixMinion usage.

> 
>      Of course, nothing but "sent SMTP to anybody" is good enough in
>      situations when recipients do not want to admit that they are 
>      recipients of anonymous messages--see Observation 7 below.  (Roger 
>      made an analogy to a regulation during the 1950's wherein the Post 
>      Office would -- as an alleged service to the postal customer -- 
>      hold "communist propaganda" for you at your local post office, and 
>      not give it to you unless you came in and acknowledged with your 
>      that you wanted it.)
> 

There are scenarios where this would not be such a giveaway. For example 
Amnesty International, Alcoholic anonymous, etc could register that they 
want to receive anonymous mail at some addresses but not other (so that 
secretaries filter first). The same could hold for nym.alias.net: everyone 
that has an account automatically accepts to also receive anonymous mail.
I think that both opt-in and opt-out could be useful in different 
circumstances.

>      OBSERVATION 2: Running middle nodes (ones that relay to other 
>      nodes, but not to arbitrary SMTP addresses) may be relatively 
>      innocuous.  If this is so, then we can get people running those 
>      nodes who would not want to assume the burden of running an open 
>      SMTP exit.
> 

I agree.

>      OBSERVATION 3: Roger likes hybrid topologies, especially (from what
>      I can tell) ones that start with a free-route, but which end with a
>      short cascade to an exit (or destination) node.  These would seem 
>      to be a natural consequence of a system with many more relay nodes
>      than exit nodes.
> 

I truly believe that there is a clear need (we may have mentioned before) 
for a policy language where each mix puts: signature keys, encryption 
keys, expire dates, mixes it peers with, modules installed, some stats on 
latency and anonymity. Then we need a mechanism to parse this language and 
produce candidate routes, given some inputs (minimal) from the user. It 
would also be nice (wish list) to be able to get the anonymity set of the 
network from these policy files.

> SIDENOTE
> 
> - Client software should gripe about sending documents in formats like 
>   MS Word.  Word documents are less anonymous than people think.

We should certainly make a note in the documentation but I do not think we 
should go as far as filtering content, to check if people have included 
their names. Do not forget: in most "institutional" applications, where 
for example Reuters HQ wants to communicate with an undercover 
investigative journalist in Angola. The two communicating parties are 
quite happy knowing who each other is, but no one in the middle should be 
able to make a connection.

> 
> SINGLE-USE REPLY BLOCKS (SURBS) AND MULTI-USE REPLY BLOCKS (MURBs).
> 
>     - SURB and MURB are short and easy to say.
> 
>     - We should look, according to Paul, at "Flash Mixes". He says they 
>       may help us achieve MURBhood.
> 

I had a look at these a while ago. As I recall they were complete systems 
(multiple nodes working together in a quite synchronized way) that 
provided a ZK proof that there was a shuffle and that all the input 
plaintext is in the output. They are horrible constructions, that I would 
definetly be condemned to code if I end up in Hell. It is not clear how 
they react to failures, what their average latency is etc. I will have a 
look again.

> THE RELATION OF MIXMINION TO CONNECTION-BASED SYSTEMS
> 
>     - Will the lack of MURBs cause users to use connection-oriented 
>       systems instead?  
> 
>     - There is reason to suspect that virtual circuits and long-term  
>       connections risk anonymity, or at least make it harder to get.
> 
>     STRATEGY NOTE 1: Let's not build in insecure or bogus versions of 
>     features just to try to woo users away from connection-based 
>     systems.
> 

As I have mentioned to Roger before all connection based system need to 
establish the connection first using a mechanism very similar to 
MixMinion. In that sense it is not implosible to create on top of MixMinion 
a streaming module that will then relay streams anonymously from one mix 
to another.

>    STRATEGY NOTE 4: We should keep the trust network human for now.
>    We should track performance of nodes, but let humans decide how to
>    choose paths.

As I said before I would rather have an automatic generation for random 
routes, or at least a validator of routes against server policies.

>    OBSERVATION 8: Crypto is still a munition: though the old export 
>    controls are no longer in effect, the wide scale adoption of crypto 
>    is not (in some circles) considered a desirable goal.
> 

Too bad for these circles, because encryption is now out there.

>    OBSERVATION 10: Does educating users on how to use Mixminion well 
>    make us liable or legally vulnerable?
>       - Obviously, we should ask a lawyer.  Roger knows somebody 
>         appropriate.
>       - Probably not, so long as we aren't explicitly urging people
>         to commit crimes.
>       - Nevertheless, harping on the possible criminal applications of
>         our service might make it seem (falsely!) that we condone 
>         criminal behaviors, and provide a means for legal harassment.  
>         Thus...
> 
>    STRATEGY NOTE 7: We should only include legitimate, legal, generally 
>    positive examples in our documentation.  (e.g., let's not write 
>    "Alice wants to hire a hit-man named Bob to kill Carol, who sold her 
>    some bad heroin."  Let's stick to "Alice wants to tell an 
>    investigative journalist named Bob about the bogus accounting 
>    practices of her employer, Carol."  It's not that the former 
>    necessarily makes us legally liable: it's just bad PR.)
> 

Both examples above are criminal in some jurisdiction. Generally it is 
safe to assume that

THEOREM 1: For every action A there exists a jurisdiction B in which A is 
illegal or immoral.

Therefore I do not think we should be too bothered, but I agree that we 
should emphasize the "good" use that MixMinion could have.

>    OBSERVATION 11: End-user convenience is inversely proportional to 
>    resistance against adversaries who can get access to your computer.
>        - In this case, saving messages is a no-no.
>        - Preference files are evidence, esp. if they name names.
>        - We should provide client software that works for users with 
>          these needs and for users without them.
>        - An intermediate option is to encrypt such data, as GPG encrypts
>          keyrings.
> 

Full system integration with other tools that provide privacy and 
anonymity is outside the scope of this project I feel. I think we should 
concentrate on the security and robustness of the communication and let 
other people construct the (A)inux OS that integrates MixMinion as default 
(and only) way of talking to the outside world, the steganographic file 
system, Tempest fonts, and the halt and self destruct button on the front.

> SIDENOTES:
> 
> - We may be able to prevent Gzip bombing by requiring Gzipped packets   
>   to have the output size in their headers, and by limiting that size.
> 

Good idea!

> - What do I need in order to implement?
>   - For now, I need a spec more than anything.

The spec should be ready by Friday, for you, my dear friends, to comment 
on. 

<Advertisement>
The spec is a simplified and rewritten version of the previous spec, 
reflecting our discussion. It contains pseudo code for processing the 
packets (That should go up to Andrei for proof), and a detailed 
description of the MMTP (MixMinion Transport Protocol) that is a forward 
secure channel, with cashed keys, that even if compromised would require 
the baddies to look at all communication to decrypt it (this should go 
through some protocols people around here for verification)! 
</Advertisement>

>   - Soon, we'll need to discuss licensing and strategic decisions.
>   - I'm putting off writing crypto and net stuff; I'll have to do so
> soon.

The crypto we are using is Standard NIST stuff (SHA-1, Rijendal) and 
PKCS#1 RSA-OAEP (Maybe modified a bit) encryption and RSA PSS signatures.
Maybe there are some libraries around that implement them. Otherwise 
contributing open source libraries doing these is by itself a valuable 
contribution.

Yours,

George