[tor-dev] (Draft) Proposal 224: Next-Generation Hidden Services in Tor
desnacked at riseup.net
Sun May 24 15:33:21 UTC 2015
John Brooks <john.brooks at 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
> 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.
- 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.
More information about the tor-dev