Re: [tor-talk] some clarifications on hidden services ...

[grarpamp <grarpamp@xxxxxxxxx>]

> - Can I choose more than 3 random relays to announce my hidden service to ?

Like circuit length, I believe the spec allows for an arbitarary
number of IntP's
in the Rendezvous-Service-Descriptor. But I don't think there is a widget for
soft adjusting either yet. Likely because the benefit to most would be minimal,
unless your IntP's are being flooded.

Also, you are 'announcing' (publishing) to what is likly 2x3=six(6) HSDir's a
list of three(3) IntP's. None of which 'relay' the userland traffic of the HS.
That job belongs solely to the RP (and the client and HS paths to it).

As an aside, since the clients pick their RP at random, that also covers a
busy HS's need to spread its traffic load across multiple frontend service
paths (though it's still governed by speed of said paths and its EG's).

I'm sure there's a trade off in not having all the HSDir's all carry all the
RSD's. Probably just in HSDir speed/traffic (were such a backend carriage
protocol needed) vs. any given success rate of whoever is trying to DOS
the current HSD subset in an attempt to de-index an onion (which
cyclically evades with time anyways, ad nauseum).

It would be interesting to see if such roving floods on HSDir's and IntP's
are observed in the wild. With the old versions of RSD's, the fixed authorities
were probably flooded for that purpose as well.

Seems like a distribution game. Assuming that's what you meant by the question.


Last thing about rend-spec.txt...
    188    The reason is that the introduction point does not need to
and therefore
    189    should not know for which hidden service it works, so as to
prevent it from
    190    tracking the hidden service's activity.

Assuming one has a list of known onions... one might therefore be able
to metronome
the fetching of the RSD's (from what may be observed to be their own HSDir), and
distill the IntP's (easily compared with their own node address). So I
question the
quoted sentence, and the utility of the observations to a censurious
operator....
at least for the duration the RSD is valid.

I think that upon removal of certain release trains from the consensus version
list, references to old protocols should be git committed out of the docs to
simplify their reading.

I pre-admit if wrong on some of this.
_______________________________________________
tor-talk mailing list
tor-talk@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk