replays and replies

[Paul Syverson <syverson@itd.nrl.navy.mil>]

I was thinking a little about our claim that we don't have to worry
about replay anymore. This made me think about reply circuits, where
replay could still be important. Roger has convince me that much of
what we wanted to do with replies could be done by rendezvous
servers. But, I think replies still might have a role to play, so I am
setting out the idea some while it's still fresh in mind.

The replier will have an onion that will be used to connect to the
builder. I use these terms to distinguish the user of the onion from
the builder of the onion (actually the one to whom the onion connects
need not be the builder, but let's ignore that).  Initiator and
responder still refer to the one who started the circuit and the one
who responded.

To make the reply connection, the replier has an onion skin and
address for the first OR. He uses this to make a connection to it. He
also has an extend cell that he gives to it to tell it to connect to
the next OR, etc. Once he has done all his extensions he has a data cell
that is public-key encrypted for the last OR in the route. This
contains the address and port for connecting to the builder.

Each extend should contain an integrity check, e.g., a hash of the
previous cells (I haven't thought about what we need to make this work
right.) This would prevent peel-mix-and-match attacks where the
replier or someone tries different skins in different orders to try to
learn about the route. It should be such that the route can only be
completed if the layers of the onion are used in order. We also might
want this integrity check for other reasons that have been discussed
elsewhere.  

Notice that the replier has all the data keys but still does not know
the route because he does not know to what OR the extend points each
time. But, because he has the keys, it will be possible for him to
replay this onion. We still have some replay protection because nodes
in the route cannot do the replay, only the connection initiator (the
replier) can. Also, the replier might be trusted, and it is just more
convenient or feasible for the onions to be built by the builder, etc.

Much more could be said, but gotta get back to other things.

aloha,
paul