[tor-dev] [Draft Proposal] Scalable Hidden Services

[Nick Mathewson]

On Mon, Oct 28, 2013 at 9:19 AM, Matthew Finkel
<matthew.finkel at gmail.com> wrote:
> Hi everyone,
>
> This is a proposal I wrote to implement scalable hidden services. It's
> by no means finished (there are some slight inconsistencies which I will
> be correcting later today or tomorrow) but I want to make it public in
> the meantime. I'm also working on some additional security measures that
> can be used, but those haven't been written yet.
>
> Many thanks to George for his initial feedback. I pushed this version to
> my public repo, and will continue to push updates there.
>
> In reality this is really 3.2 proposals, so the end result, if accepted,
> will look significantly different, but I'm indecisive at this point
> about which of the designs is least dangerous.

Looks cool!

Generally, I think that requiring a single node to be master is fine
in initial designs only: if we consider such a design, it's important
to have a migration path to a design where the whole service doesn't
fall over when a single leader goes down.  It's less important to me
that there be no master key, especially if that master key can be kept
offline.

I also like designs where it's not immediately obvious how many hosts
a hidden service has just from looking at its descriptor.


FWIW, I'm working on a complete revision to rend-spec.txt, since I
think the scope of hidden service changes under consideration is broad
enough that it makes sense to reconsider the entire system as a whole
rather than trying to do it one piece at a time.  I haven't even
gotten to the spec parts yet -- just the preliminaries -- but you can
see the draft in progress as it was on my desktop this morning in
branch "rendspec-ng" in my torspec repo.  I'll be putting more updates
there as I go.

I mention that here because some of the design work I'm recording
there should mitigate the dangers of distributing keys to different
hosts.

yrs,
-- 
Nick