Re: Reply blocks and tagging protection: a third variant

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

On Tue, 2002-04-09 at 09:16, George Danezis wrote:
> On Sun, 7 Apr 2002, Roger Dingledine wrote:
> > Which leads to the issue of putting destination information in the payload
> > vs the header. I'm still not convinced by George's statement that it
> > should go in the payload. First off, it seems hard to put destination
> > info in the payload of a reply block: I just don't know how it could work
> > with our encryption system. The guy using your reply block should not be
> > able to learn (parts of) your delivery info, eg by keeping transport_type
> > but changing email_address, in order to learn transport_type. Second,
> > in order for tagged (and thus random) messages to not be recognizable,
> > some messages must be plausibly all-random. These messages are the ones
> > that are encrypted to somebody, either a forward message encrypted to
> > the recipient or a reply message which has been multiply-encrypted. If
> > the destination info is in plaintext, then these payloads aren't
> > all-random. So tagged messages are discernable.
> 
> The idea is not to explicitly put all routing information in the payload. 
> Routing information should stay in the two headers. The point I tried to 
> make is that the second header depends on the correct decryption of the 
> payload and therefore if the payload is modified it is not possible to 
> continue with the delivery.

But the final email address in your latest design is part of the payload
(if it's anywhere).  That's routing information.  If I can trash the
payload (after the header switch), then I can distinguish email messages
with valid addresses from trash messages.  [I would have this
opportunity if somebody generated a SURB for which I controlled the
first and last hops.  Your design prevents this situation by making
every SURB recipient run their own node; see next graph.]

(AFAICT, the design you have specifically prevents anybody from securely
receiving SURB replies via email without running their own node.  This
is a limitation: not everybody who would like to receive such replies
necessarily has a high-availability connection of their own.)

> Note that this property is stronger then just 
> including a hash to check the payload that a malicious node could ignore.

I agree strongly with this point.
 
 [...]
> This property could be 
> implemented by a "strip N and decode using payload" operation but I think 
> it is unnecessary to provide more general operations than strictly 
> necessary (unless there are other reasons). 

Well, using the operation above removes the need for a pair of headers,
and thus (IMO) simplifies the design a good bit, and prevents wasted
space.

Really, the double-header design already two forwarding operations,
namely "tr=0", and "tr=1".  The "strip N and decode using payload"
operation is equivalent to "swap headers and decode using payload", but
just saves the trouble of having a pair of headers.  

-- 
Nick