[tor-dev] Proposal #291 (two guards) IRC meeting Wed Apr 18, 17:00 UTC

[George Kadianakis]

Mike Perry <mikeperry at torproject.org> writes:

> Mike Perry:
>> Heyo.
>> 
>> We're going to have a meeting to discuss Proposal 291. See this thread:
>> https://lists.torproject.org/pipermail/tor-dev/2018-April/013053.html
>
> Ok, we had this meeting. High level (ammended) action items are:
>
> 1. Use patches in https://trac.torproject.org/projects/tor/ticket/25843
>    to set NumEntryGuards=2 in torrc, and observe results. Please join us!
>    Stuff we are looking for during testing is on that ticket!
> 2. Merge that patch to make the torrc guard options do what we meant for
>    them to do. Probably backport it.
> 3. Descibe adversary models for our variant proposals from the notes.
>    (Why do we disagree? In Mike's case, my disagreements are because I
>     think each step is an improvement over previous/status quo -- we can
>     decide harder things later and still do better both now and later.)
> 4. Agree on an order of operations for fixes+changes, ideally such that we
>    don't block forever trying to come up with a perfect solution. Things
>    are pretty bad now. All we really need to do is agree on steps to make
>    it better.
>
> <snip>
>
> Concrete things we can do now:
> #1: ourselves set those guard params to 2 and find bugs. once #3 below is done, encourage others, like on tor-talk, to do it too.
> #2: enumerate the current situations where we use a guard other than our first guard, especially noting the ones where the attacker can make us use a guard other than our first guard. fix as many as we want to fix. maybe categorize by whether they cause us to mark our first guard as down or not.

OK, I did a bit of #2 yesterday as part of an IRC discussion with Mike
and Roger. In particular, I attempted to enumerate the places in our
codebase where we mark a guard as unreachable and hence skip it for
future circuits.

The key functions here are entry_guard_failed() and entry_guard_chan_failed().
These are called in the following places:

1) circuit_build_failed(): We blame the guard if there was an error
   during path building when we don't have the first hop open on the
   circuit yet. We don't blame the guard for errors during path
   selection.

2) connection_dir_request_failed(): We blame the guard if we fail to
   connect to a dirserver because of network error.

3) connection_or_about_to_close(): We blame the guard when we are
   closing an OR connection that started at us but never made it to
   state open. We do this because otherwise we would keep beating our
   heads against a broken guard.

4) connection_or_client_learned_peer_id(): We blame the guard when we
   receive the wrong RSA identity key from the guard during the TLS handshake.

The first 3 cases here seem to handle the cases of network errors and
unreachable guards. It's interesting how we have to handle this case in
three different places. I wonder if we are missing any other places here.

The last case seems to handle the case of network MITM attacks. I don't
see anything wrong with that, since encountering an MITM certainly means
that something bad is going on, and also an MITM adversary could also
cause one of the first 3 cases.