[tor-dev] (Draft) Proposal 224: Next-Generation Hidden Services in Tor

[George Kadianakis]

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
> 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!