Re: [tor-dev] Proposal: Merging Hidden Service Directories and Introduction Points

[s7r <s7r@xxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi,

Worth mentioning, after #15745 we rotate the introduction points after
between 16384 and 32768 (random) introductions and/or a lifetime of 18
to 24 hours (random).

If we merge introduction points with HSDirs, we have no option but to
use the same introduction points, regardless how many INTRODUCE2 cells
we get through them, until the new shared-RNG consensus value (24
hours normally, in case nothing bad happens which makes us failback to
disaster protocol for shared-RNG where we use the previous known one).
So if we adopt this, the IPs will have a fixed lifetime of 24 hours,
no less or no more (unless disaster).

Switching IPs randomly is not something we don't care about. They see
exactly how popular a hidden service is, and they are always on a live
circuit with the hidden service directly. The HSDirs in our current
design allow us to be less paranoid about them, since they just hold
descriptors, we don't keep live circuits with them, and the worse they
can do is perform a DoS by not serving our descriptors - this will be
mitigated with consensus shared-RNG anyway.

This will leave #15714 with all its child tickets without subject to
bind to.

We could complicate things a little bit, and always select using the
consensus shared-RNG 2 sets of 6 HSDirs+IPs each. Initially we start
with the 6 relays in the first set as IPs, and after between 16384 and
32768 (random value) INTRODUCE2 cells received we close the circuit to
one IP, mark it as dirty and open another circuit with one from the
second set. However, this will be painful for the clients who will
also select and try introduction points randomly and will get
failures. Considering we now retry IPs and not give up after first
failed attempt, this could complicate it even further.

To be honest I like the idea of merging HSDir with introduction point
functionality in next generation hidden services, but it requires more
code, more effort, more pain regarding legacy compatibility (which
will be a problem). It has some unquestionable, clear benefits which I
totally agree to, but I am not fully convinced we make a good deal
here if we think about the tradeoffs.

Also worth mentioning, said it on other threads but saying it here
since it's on topic: the OnionBalance testings I have performed
demonstrated in practice, in the real network, that 6 introduction
points for a hidden service should be just fine - the Guard will
become a bottleneck long before the introduction points. I had on
average about 2000 concurrent rendezvous circuits in any time of the
day, this means an enormous amount of rendezvous circuits per 24 hours
just with 2 introduction points.

On 8/20/2015 8:23 PM, George Kadianakis wrote:
> Michael Rogers <michael@xxxxxxxxxxxxxxxx> writes:
> 
>> On 12/07/15 22:48, John Brooks wrote:
>>> 1.3. Other effects on proposal 224
>>> 
>>> An adversarial introduction point is not significantly more 
>>> capable than a hidden service directory under proposal 224.
>>> The differences are:
>>> 
>>> 1. The introduction point maintains a long-lived circuit with 
>>> the service 2. The introduction point can break that circuit 
>>> and cause the service to rebuild it
>> 
>> Regarding this second difference: the introduction point 
>> (cooperating with a corrupt middle node) could potentially try
>> to discover the service's guard by repeatedly breaking the
>> circuit until it was rebuilt through the corrupt middle node.
>> Would it make sense to use vanguards here, as well as on
>> rendezvous circuits?
>> 
> 
> Hello,
> 
> currently we address this intro point guard discovery attack by 
> having hidden services retry only 3 times. After those 3 times, 
> they ditch that intro point and pick another one.
> 
> That said proposal 247 suggests that hidden services use vanguards 
> for both rendezvous and introduction point circuits anyway.
> 
> Take care!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBCAAGBQJV1h4yAAoJEIN/pSyBJlsRAFcIAJrRto6jxLIC75RsU+WEhiVf
Nf+btz5fcImopa/au5DrzkLmna4AR33qQWnGERoYBCpjlca0SX+fb52z/NmBasYn
OGK0/zlhasdgHGNGbT1wbL3O7OqBwSaRnpY3e4gGvsl+UQi8OUj/v4CkOq3qMexQ
xFersDHOgnc1I4neSBmaAosRIc4WUQ8JxHjR7/doeOi8GBSSZCdwxk2LN7p+Ap6u
tpErzvQx2kR3TRkQEVNk0jysy63agspvOy3Kq/Hi8IpOND9L+ZqpdOl17bqyqLWG
ZCEKpqe6Vf1pcn6k1EexkRfGYkSuCqN+92cAqhDCdP5oqy6LaN4pA9vPdBepgQQ=
=/f4T
-----END PGP SIGNATURE-----
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev