On 12 Feb 2019, at 04:49, Ian Goldberg iang@uwaterloo.ca wrote:
Another issue not addressed by the current proposal is how to handle the "not all the relays have upgraded" problem.
And how to handle the onion service protocol (in detail).
Here's one possible migration path: (I think it works, but we should spec these changes in detail.)
Step 0: graceful protocol upgrades on new relays
The walking onions EXTEND and CREATE cells are different from the legacy cells. (If the walking onions CREATE cell was exactly the same as the current CREATE cell, clients would only need to check the current hop's protocols.)
So, when extending, a client: * sends the certified index as an additional link specifier in the EXTEND cell * if both relays support the protocol, the EXTENDED cell contains an ENDIVE in addition to its legacy content. Otherwise, it is a legacy EXTENDED cell.
For v3 onion services: * service descriptors contain the certified index as *an additional* link specifier * client intro EXTENDs contain the certified index as *an additional* link specifier * client INTRODUCE cells contain the certified index as *an additional* link specifier * service rendezvous EXTEND cells contain the certified index as *an additional* link specifier
(If we implement unknown link specifier passthrough from the v3 onion service proposal, these protocol upgrades should happen automatically.)
For v3 single onion services: * introduction points are looked up via a 3-hop path, like guards, using a random middle index * rendezvous points are connected to directly, using their IP and ID link specifiers. (A 3-hop lookup is too slow for rendezvous.) * the rest of the protocol remains the same
(v2 onion services can't support walking onions, because their protocol isn't flexible enough.)
Step 1: require protocol upgrades on new relays
For standard paths, like Step 0, but: * if both relays support the protocol, send the certified index as *the only* link specifier in the EXTEND cell
For v3 onion services: * descriptors remain the same as step 0. (The link specifiers in the descriptor can be 24 hours old, so the client can't rely on the service's view of the intro's protocols.) * if both relays support the new protocol, client intro EXTEND cells contain the certified index as *the only* link specifier * client INTRODUCE cells remain the same as step 0. (To support single onion services, which need legacy link specifiers.) * if both relays support the new protocol, service rendezvous EXTEND cells contain the certified index as *the only* link specifier
For v3 single onion services, the protocol remains the same: * rendezvous points are connected to directly, using their IP and ID link specifiers. (A 3-hop lookup is too slow for rendezvous.)
Step 2: ignore legacy relays
Like Step 1, but: * check the consensus for a flag that tells us to ignore legacy relays
v3 onion services continue to include legacy ID and IP link specifiers, for older tor versions, and single onion services.
Step 3: remove legacy onion service descriptor link specifiers
Once all onion services and clients support walking onions: * service descriptors contain the certified index as *the only* link specifier. (Clients will have to make a multi-hop path. But that's ok, because we don't support Tor2web on v3 onion services.) * client INTRODUCE cells continue to include legacy IP and ID link specifiers, to support single onion services.
This upgrade process leads to some more questions:
1. How do clients discover protocol versions?
We can do one or more of: * ENDIVEs contain a list of supported protocol versions for each relay, or * clients ask the current hop for a copy of its descriptor, which contains protocol versions (see below for tradeoffs), or * we have a flag in the consensus that tells clients if they can safely ignore legacy relays
2. How do clients keep their guard information up to date?
Two options: * They ask the guard for its descriptor. * They re-extend to the guard via a 3-hop path
Fetching the descriptor could also help us in situations where we need to discover less common information about the relay. But it's slower, and it looks different to the relay, and on the wire. So we might want to avoid it. (That said, Tor already fetches descriptors from bridges.)
3. How do we minimise Tor version distinguishers?
We should implement all the stages in a small number of Tor releases, then active them using a consensus parameter.
We should try to implement onion service link specifier passthrough in the same release as full onion service IPv6 support, so we have fewer onion service version distinguishers.
If we implement it later, we might end up with: * 2-4 IPv6 distinguishers (until these versions are unsupported) * 1 passthrough distinguisher * 1-3 walking onions stage 0/1/2 distinguisher(s)
T