Re: [tor-dev] Revisiting prop224 overlap descriptor logic and descriptor lifetimes

[Roger Dingledine <arma@xxxxxxx>]

On Mon, Jun 13, 2016 at 03:48:39PM +0300, George Kadianakis wrote:
> The main issue for me right now is that I can't recall how this helps with
> clock skewed clients, even though that was a big part of our discussion in Montreal.
> 
> Specifically, I think that clients (and HSes) should determine the set of
> responsible HSDirs (i.e. the current time period) based on the "valid-after" of
> their latest consensus, instead of using their local clock. This way, as long
> as the client's skewed clock is good enough to verify the latest consensus, the
> client will have a consistent view of the network and SRV (assuming an
> honest/updated dirguard). I tried to clarify this a bit in commit 465156d, so
> please let me know if it's not a good idea.

Interesting idea! I think I like it. You're right that in Montreal
we were thinking in terms of client clocks, and we might be able to
reduce the problem (both in frequency and in magnitude) by considering
the time in the last consensus we have.

Another argument in favor of using the last consensus is that we will be
picking the "relays that are closest to the right location in the hash
ring" out of our last consensus already. (That is not a strong argument
in favor though, I think, since in theory there won't be so much churn
in a day that all of the relays in our last consensus will become wrong.)

All of this said, it seems like you are basing your arguments on some
expectations about how clients handle consensuses that have surprising
dates in them (surprising either because the client's clock is skewed,
or because their directory guard gave them the wrong consensus). How
*do* clients handle these situations? If we could get the intended /
expected behavior written down, then we would have a better chance of
identifying bugs in it that we can then fix.

For example, do I as a client just ignore and discard a consensus from
6 hours in the future? I don't remember the answer, so I can't do a good
job at analyzing your proposed change.

Thanks!
--Roger

_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev