Patches (maybe) for proposal 110

[Nick Mathewson]

On Wed, Aug 22, 2007 at 03:31:01AM -0400, Roger Dingledine wrote:
> On Tue, Aug 21, 2007 at 05:43:35PM -0400, Nick Mathewson wrote:
 [...]
> > The third patch enforces the protocol by:
> >     A) Disallowing any RELAY_COMMAND_EXTEND cells without the special
> >        cell type, and
> >     B) Closing any circuit where too many cells of the special type
> >        are sent.
> > 
> >   Rule B is not quite right: the rule is not "You may send no more
> >   than X special cells;" the rule is "special cells may only occur as
> >   the first X cells on any circuit."  (See proposal 110, "Design"
> >   section, last paragraph.)
> 
> Right.
> 
> But Nick, also see the 'additional complexity' section. It might be
> smart for clients to send the first K of them as relay_early, but for
> servers to enforce it by a "no more than K ever" rule. This could give us
> more flexibility if we want it later -- I don't think it increases the
> damage that can be done via the infinite circuit attack, though sending
> a relay_early cell later on would tell everybody in the circuit what
> you're up to.
> 
> (If we opt for this approach, we may find that RELAY_EARLY is now a bad
> name. Hm.)

Right.  Personally, I'm not convinced that this is actually something
we'll want to do down the road, but I don't immediately see any way it
can hurt.

Other names: RELAY_COSTLY? RELAY_LIMITED?  RELAY_CAN_BE_EXTEND?
RELAY_HEAVY?

> 
> > Here's a way that we could get the new protocol in faster.  It
> > requires that something like proposal 105 is implemented, so that part
> > of negotiating a Tor connection is learning which connection protocol
> > version the other router supports.  Here goes:
> 
> Actually, I had meant for us to be able to do phase 1 and phase 2 quite
> close together (e.g. both in the 0.2.0.x timeframe), and it doesn't depend
> on proposal 105. Basically, Alice should use a RELAY_EARLY cell when
> all the nodes in her path would understand it, and not otherwise. She
> has descriptors for all of them, after all, so she's in a fine position
> to know when it will work.

The problem is that this tells an attacker running a node whether the
other nodes in Alice's path are or are not among those that have
upgraded to support RELAY_EARLY.  If the number of nodes that supports
R_E is small, then an exit can narrow down Alice's entry pretty easily
by noticing that it has just gotten an R_E cell.  Worse, if the number
of nodes that _don't_ support R_E is small, than an exit can narrow
down Alice's entry by noticing that it has just gotten a _regular_
relay cell.

Sure, 105 has a bit of complexity.  But we need it anyway for other
stuff, and we might as well use it to let us do 110 a little more
securely.

Thoughts?
-- 
Nick Mathewson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 652 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20070823/d31d0fb2/attachment.pgp>