[tor-dev] Proposal 205: Remove global client-side DNS caching

[Julian Yon]

On Tue, 27 Nov 2012 20:53:03 -0500
Nick Mathewson <nickm at alum.mit.edu> wrote:

> On Tue, Nov 27, 2012 at 10:08 AM, Julian Yon <julian at yon.org.uk>
> wrote:
> >
> > So, perhaps have a cache but only consult it for making decisions
> > about whether to use a circuit, not for resolving client requests?
> > Although this is still vulnerable to poisoning, that could perhaps
> > be mitigated by capping the TTL at some small value.
> 
> There's an interesting idea! I wonder, can we come up with a way to
> tell whether it's necessary?

It might be possible experimentally. Implement it as an optional
codepath. Run in both configurations for a while, and in each case
monitor the number/percentage of refused connections the average added
latency due to refusal, and the percentage of total latency that this
represents.

> It's not likely to help typical clients, since microdescriptor-users
> (and all IPv6 users) don't see the full exit policy, but only a policy
> summary.

Hmm. From the summary we know which destination ports we can use, so
the time we have a problem is (e.g.) when an exit allows port 80 in
general but not for the particular IP/netblock in question. This is a
rare case, but when we do hit it, without DNS caching every single
request is going to bounce, isn't it? Given the number of resources on
a typical modern webpage, this implies that occasionally somebody is
going to find that suddenly their latency goes through the roof because
of an unlucky combination of website and exit. And so maybe it's
not quite as simple as the above experiment :-/

What's needed is to determine whether the effect is large enough that
it needs to be accounted for, or whether it's just an inconvenient
corner case. So I think maybe performing some measurements using an
artificially small ExitNodes list, giving a high probability of hitting
a restrictive exit, may be necessary (obviously the call that Roger
mentioned to policies_set_node_exitpolicy_to_reject_all needs to be
disabled or it'll just get blacklisted on the first hit).

And of course you're right, unless clients have some way of knowing to
avoid the exit it's a moot point, so...

> My main worry here is that an exit could give different clients
> different exit policies.  I'm not sure yes if there's a clever way to
> bootstrap that into a full attack, but generally when you give an
> attacker the ability to give different clients different views of the
> network, you can run into trouble.

Ok, that's a fair concern. Two variations sprang to mind immediately:

(1) Add a hash of each router's full exit policy to the consensus. The
client can use this to verify that it's being given the same info as
everyone else. For policies that are fully covered by the summary, this
line could be omitted (as it should never be needed).

(2) The first time an exit rejects a connection, ask another party
(directory authority/mirror) for the full policy at that point. However,
I see that a related idea has been floated before (Proposal 141).
Presumably there were good reasons why that proposal wasn't
implemented. Certainly I can immediately see the potential for
information leakage.

But as I was writing the top half of this email I then thought:

(3) Don't bother trying to ascertain the full exit policy, but rather
maintain a simple table of exit/IP/port combinations that have been
rejected and consult it when building/using circuits. This requires no
protocol changes (win!) at the cost of no longer blacklisting dishonest
exits entirely. Some mechanism for expiring entries would probably be a
good idea, and/or maybe hold it in a circular list so that there's a
maximum number.

As far as I can see, all of these would mitigate Roger's attack, and
(3) feels like it should be particularly easy to implement and while it
doesn't solve #1774 I can't see how it introduces any new problems.
Thoughts? Is it really that simple?


Julian

-- 
3072D/F3A66B3A Julian Yon (2012 General Use) <pgp.2012 at jry.me>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 230 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20121129/9ed3e12a/attachment.pgp>