On Thu, Apr 23, 2020 at 5:26 PM teor teor@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,