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?
- John