[tor-dev] Proposal 315: Updating the list of fields required in directory documents

Nick Mathewson nickm at freehaven.net
Mon May 11 13:49:05 UTC 2020


On Thu, Apr 23, 2020 at 5:26 PM teor <teor at riseup.net> wrote:
>
> Hi Nick,
>
> This proposal is missing the "bridge" case.
>
> Bridges are more complicated, because we have at least
> 3 kinds of bridges:
> * bridges distributed by BridgeDB
> * bridges distributed with apps (such as Tor Browser)
> * private bridges
>
> Bridge option transitions are also more complicated, because clients
> download bridge descriptors directly from their configured bridges.

Thank you!

I think that the transition isn't too bad, since the partitioning that
a bridge _could_ do by maintaining an obsolete descriptor format is
limited in its impact, since the bridge already (typically) sees the
client's IP address.  So the only difference is that we need to be a
little more careful about when we start  to require the fields, since
bridges sometimes  lag the versions supported by the rest of the
network.

I've update the proposal with these paragraphs:

   Bridge relays have their descriptors processed by clients
   without necessarily passing through authorities.
   We can make fields mandatory in bridge descriptors once we
   can be confident that no bridge lacking them will actually
   connect to the network-- or that all such bridges are safe
   to stop using.

   For bridges, when a field becomes required, it will take some
   time before all clients require that field.  This would create a
   partitioning opportunity, but partitioning at the first-hop
   position is not so strong: the bridge already knows the client's
   IP, which is a much better identifier than the client's Tor
   version.

cheers,
-- 
Nick


More information about the tor-dev mailing list