[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