Older proposals in need of discussion: 149 ("Using data from NETINFO cells")
Nick Mathewson
nickm at torproject.org
Fri May 22 19:47:47 UTC 2009
Last August I sent out proposal 149, but it never got much discussion
on this list. (Looking at the archives, I can't find any.) Here's
the paragraph that hasn't much been implemented:
We need to think about attackers here. Just because a router tells
us that we have a given IP or a given clock skew doesn't mean that
it's true. We believe this information only if we've heard it from
a majority of the routers we've connected to recently, including at
least 3 routers chosen at random. Routers only believe this
information if the majority includes at least one authority.
This isn't so good:
- It's less secure than we would like for clients. If I can block
your network connection selectively, I can make you only connect
to routers I control, who can lie to you about your IP and the
time.
- It's sometimes useless for clients. If a client's timestamp is
in the distant past or future, it may not believe in the quality
of _any_ router info, and so not actually try to connect to
anybody and learn the time via a NETINFO cell. Or it might fail
because the other side's x509 certs will look invalid. Or it
might fail because its own x509 certs will be invalid.
- It's less functional than we want for servers. Most servers
don't go out of their way to talk to the authorities, and so they
don't often get time/ip info this way.
So I propose that we amend 149 as follows:
1) Clients and servers alike should believe the time from a netinfo
if all of the following hold:
- They have heard similar times from a majority of the servers
they have connected to.
- The majority contains at least 3 servers not in the same
family.
- A majority of the connections that the node has attempted were
successful.
2) Clients don't care about their own IP. Servers should consider
testing an IP given from a netinfo cell if it meets the criteria
for time differences in 1) above, and they don't already have a
working IP.
3) We should stop rejecting connections entirely because of expired
or no-longer-valid x509 certificates. Instead, we should allow
the connection to continue, but not believe the identity of the
other side.
4) We should check the code to see what clients do with seemingly
expired or future consensus documents. Clients should always
provisionally accept a consensus if it is newer than any
consensus they have. They should then contact nodes until they
know what time it is.
Thoughts?
--
Nick
More information about the tor-dev
mailing list