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

[John Brooks <john.brooks@xxxxxxxxxxxxxxxx>]

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
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev