Re: Minion paper comments

[Adam Shostack <adam@homeport.org>]

On Tue, Jan 14, 2003 at 10:03:09AM -0500, Roger Dingledine wrote:
| On Mon, Jan 13, 2003 at 10:47:41AM -0500, Adam Shostack wrote:
| > Its good work there.
| > 
| > I question one of your high level decisions, reply blocks on three
| > grounds:
| > 
| > 1) Its not clear how useful it is (more below)
| > 2) Its a new mechanism that has effects throughout the design
| > 3) It makes the entire design more complex.
| > 
| > Usefulness:  Without email client integration, reply blocks are
| > unlikely to be used.  They're complex, clunky, and hard.  (Can I email
| > alice today?)
| 
| SURBs are a building block. You're not generally meant to use them
| yourself. But once we combine them with nymservers, then we basically
| have remote pop servers from which you can anonymously retrieve your mail.

No, I don't buy that.  Once you combine SURBs with nymservers, we have
a complex system which allows someone who's computer is always on so
it can refresh the replyblock pool to get replies without apas.

		   SURB/Nymserver	   POP3
speed:		   batch		   realtime
configuration:	   ?			   enter a popserver, account,
						 pw
maintanance:       Refresh SURB pool	   pay up

| Users who don't need to keep anonymity can mail alice@nym.alias.net and
| it will work its way to alice, whoever she is. Those who want double
| blinding can deliver the mail via the Mixminion network to the nymserver.
| 
| Near as I can tell it, type i remailers still get quite a bit of use,
| because they're the only way to do nyms. Yet they're very insecure.
| 
| The complexity from the design comes not simply from the secure reply
| blocks, but also from the goal of wanting to combine the anonymity sets
| of forward messages and replies. We could have used any of a number of
| simpler designs if we were ok with letting nodes distinguish forwards
| from replies.

Yes.  And I think that it may be worth reopening tht.

| > A high level goal that's missing is N: deployability.  We have order
| > zero remailers, and order zero remailer users.  Those need to be
| > fixed.
| 
| That's the first goal in Section 3 (page 3). Do you think we should
| emphasize it more?

Yes, I think it should go into the overview, too.

| > At the end of IV.a, I think a brief review of LBCs are in order, if
| > you choose to keep them.  I think that its worth removing
| > psuedonymity, because I think that the baroque design needed (new
| > primitives?) is a net loss.
| 
| What do you mean here by 'removing pseudonymity'? Do you mean worth
| allowing mix nodes to distinguish between forwards and replies?

Yes.

| If so, then you may be right. We tried to push through our goals and get
| the simplest design we could that met all of them. But it might not be
| worth keeping all of them. Here's an argument Nick gave me a few days
| ago for why it might be ok:
| 
| * If Mixminion takes off, it may well be because of the nymserver
|   feature. Most use will be sending mail to nyms.
| * Since for a given message M delivered to a nym, there will be a
|   corresponding M' when it's delivered to the nym's owner, then about
|   half the traffic on the network will be forwards, and half replies.
| * So while we did in fact cut the anonymity sets in half, each of them
|   is still large enough to be something.

That addresses use, not deployment.  I agree that more users is a win,
but more mixes is also a win.  Now, its not clear to me that removing
SURBs will increase the number of mixes, and in fact, I don't think it
really will.  But it will make analyzing mixminion much easier.

| > In 5C 'The fewer exit nodes,' I'm not sure I buy this; is one exit
| > node with 10 messages really worse than 10 nodes with one message?
| 
| Well, the intersection attack, which is one of the most effective attacks
| against Mixminion, requires that the adversary observe the sender and
| the receiver.
| 
| If observing a single node means you get to observe many receivers,
| then we've made this attack even easier.
|
| Part of the unspoken security hope from a free-route mix network is that
| actual global adversaries are rare, and it's worth protecting against the
| not-so-global ones too. If we seriously thought most adversaries would be
| global, then we'd probably be using a cascade. (I speak only for myself
| in this paragraph, and my intuition changes weekly. Anonymity is hard. :)

I think this is a reasonable analysis, but I think it should be
stated.  The on-paper threat model says GPA.  Which causes me to
notice, design documentation is not listed in the Mixmaster flaws.

Cypherpunk barbie says "Heh!  I hope factoring is hard!"

| > In VII, I don't buy your more liability claim.  Do you mean civil or
| > criminal?  Where's the legal support?  (This goes back to my
| > questioning of SURB.)
| 
| <wave hands here>
| I'd be interested in hearing your take on this one.

Well, really, my take is that ZKS operated a POP service without big
legal trouble.  In fact, I don't think we had any legal trouble, but I
could be wrong.  We did have economic trouble, but that came from
building the system with paid network operators.

ZKS's POP service was over a real time net, which is less secure than
Minion may be, but more secure than Type I.  I think it may be a
better solution to the reply issue.  Unfortunately, a lot of the docs
that went into these decisions contained business discussion that we 
were not interested in releasing, and so the Freedom server source
(which includes the pop services, the directory service, and
everything else) does not include the documentation that explains it.

Adam


-- 
"It is seldom that liberty of any kind is lost all at once."
					               -Hume