Re: SMTP service (was: Reply blocks and tagging protection: a thirdvariant)

[Nick Mathewson <nickm@alum.mit.edu>]

On Tue, 2002-04-09 at 22:05, Zooko wrote:
 [...]
> Anyway, it kind of seems like George is also envisioning a similar separation 
> but that Roger is thinking of SMTP and Mix being more integrated.  Let's talk 
> this out.

I think I agree with what Roger is saying, but let me clarify: I'm not
suggesting _integration_ between SMTP and Mix.  Instead, I think that
good design requires that SMTP _not_ take its delivery information from
the payload.

Here's why.  A while ago, George wrote,
>Recipients that benefit from anonymity properties will need to run an 
>application that understands MixMinion but do not have to be relays 
>themselves (they simply do not advertise keys, and the software only 
>supports packets with the "bit" set to 1 and drops the others).

In other words, the current design doesn't support SURBs with SMTP. 
Here are two reasons why it can't, without putting delivery info in the
headers:

Reason 1: BEAR, SURBs, and SMTP.  Suppose that delivery info is in the
payload.  Concretely, suppose that an email message to me must begin
with DELIV="smtp\nTo: nickm@alum.mit.edu\n".  If this is the case, I
cannot create a SURB that will end with email getting sent to me. 
(Because of the all-or-nothing encryption of the payload, I can't help
the sender create a message beginning with DELIV without revealing
DELIV.)

[Below, assume we overcome the objection above, and build SMTP SURBs.]

Reason 2: Tagging and hiding.  In the scheme Roger advocates, only the
recipient of a message can tell the difference between a tagged
(scrambled) payload and a SURB reply, since both will look like junk to
outsiders.  On the other hand, if the delivery info is in the body, then
the final node can also tell the difference between a SURB reply and a
scrambled payload.
------------------

Why this matters:
As shown above, if the delivery info is _not_ in the header, you cannot
have recipient-anonymous delivery by any mechanism other than Mix.  This
is not a big burden for the NYTimes reporter interviewing a human rights
activist, but it's a tremendous burden on the activist.  Almost
everybody can check email from a net cafe more easily than they can run
software listening for Mix requests.

Thus, I believe that:
  Conclusion 1) SURBs that deliver via SMTP are a desirable feature, and
omitting them would be a step backward.
  Conclusion 2) SURBs that deliver via SMTP are unachievable if delivery
info is in the payload.
  Conclusion 3) SURBS that deliver via SMTP _can_ be achieved if we put
delivery info in the header.

This would create problems of its own, but we could solve them.  First
of all, we wouldn't want to RSA_OAEP the whole header, since headers for
some delivery types might be over the safe input limit.  Instead, we
could just RSA_OAEP the master secret, and a hash of the rest of the
headers, and Rijndael the rest of the headers.

How does this sound?  Which of my premises or conclusions do people
disagree with?

Yours,
-- 
Nick