John Brooks john.brooks@dereferenced.net writes:
It occurred to me that with proposal 224, there’s no longer a clear reason to use both HSDirs and introduction points. I think we could select the IP in the same way that we plan to select HSDirs, and bypass needing descriptors entirely.
Imagine that we select a set of IPs for a service using the HSDir process in section 2.2 of the proposal. The service connects to each and establishes an introduction circuit, identified by the blinded signing key, and using an equivalent to the descriptor-signing key (per IP) for online crypto.
The client can calculate the current blinded public key for the service and derive the list of IPs as it would have done for HSDirs. We likely need an extra step for the client to request the “auth-key” and “enc-key” on this IP before building an INTRODUCE1 cell, but that seems straightforward.
The IPs end up being no stronger as an adversary than HSDirs would have been, with the exception that an IP also has an established long-term circuit to the service. Crucially, because the IP only sees the blinded key, it can’t build a valid INTRODUCE1 without external knowledge of the master key.
The benefits here are substantial. Services touch fewer relays and don’t need to periodically post descriptors. Client connections are much faster. The set of relays that can observe popularity is reduced. It’s more difficult to become the IP of a targeted service.
One notable loss is that we won’t be able to use legacy relays as IP, which the current proposal tries to do. Another difference is that we’ll select IPs uniformly, instead of by bandwidth weight - I think this doesn’t create new problems, because being a HSDir is just as intensive.
Could that work? Is it worth pursuing?
This seems like it could work, yes.
Some comments:
- If I'm not mistaken, theoretically this idea could even work with the current hidden services system, but because of the lack of blinded keys the IP would know which hidden services it's serving.
- As you said, this also assumes that we have first solved #8239 ("Hidden services should try harder to reuse their old intro points") in a reasonable manner.
- While HSDirs and descriptors are not very elegant, they make the protocol more backwards/forwards-compatible. The descriptor is a whole document that contains various informations on how the client can complete the rest of the rendezvous.
As an example, by making IPs the first contact here, we make it harder to change the rotation speed of IPs in the future (except if we encode that information in the onion address or something).
FWIW, even in this new system, the IP could pass a "descriptor" to the client, when the client requests the encryption/authentication keys of the IP.
- I would like to read more on how the hidden service derives the blinded signing keys to sign the intro point crypto keys. It seems to me that the hidden service and the client need to derive the same keys and assign them to the same IPs, so that the client can correctly verify the IP crypto keys. I wonder if this will be problematic given that the client and the hidden service might have different views of the network.
All in all, this seems worth specifying further to see if any unexpected problems appear.
Thanks!