Re: When is the 'MyFamily' setting unnecessary?

[Gregory Maxwell <gmaxwell@xxxxxxxxx>]

On Sun, Sep 12, 2010 at 6:53 PM,  <andrew@xxxxxxxxxxxxxx> wrote:
> On Sun, Sep 12, 2010 at 02:38:18PM +0200, tor_ml@xxxxxxxxx wrote 1.1K bytes in 31 lines about:
>> If it is technically not necessary, because tor would never use certain
>> nodes in one circuit. I would understand people running >20 nodes that
>> do not use 'MyFamily'.
>
> It's easy, put all 20 nodes in the MyFamily line and just use that line
> for all 20 nodes.
>
>> If there are certain rules I would stop asking people to set MyFamily if
>> one of these rules apply in the concrete scenario.
>>
>> So there are no rules beside the "/16 network" - rule?
>
> Perhaps it depends on what you mean by "rule". ÂThe /16 network
> diversity is in the tor source code. ÂThere are other proposals in the
> mix for circuits to contain a unique AS and/or a unique continent per
> node.

A unique AS would be a much better restriction than unique /16...
unique /16 is really just a weak proxy for unique AS.

Even ignoring the other useful disclosure properties of myfamily you
shouldn't skip disclosing the family even if the nodes are in the same
/16 simply because that restriction may be replaced with another one
(e.g. same ASN) in the future.

It is a bit unfortunate that myfamily adds a fair bit of configuration
load (N^2) as the number of nodes becomes large, it's especially
annoying if you slowly add nodes to a family since you have to go back
and hit the all the other configurations for every node you add.

Has anyone previously suggested using a shared secret for family
configuration?  The protocol might look something like this:

The user configures a secret per family which the node is a member of.
For each family the secret is processed with key strengthening (such
as PBKDF2 or, better, scrypt) and a (say) 64-bit family ID and a
128-bit family-key are derived.  Nodes publish the family IDs.  Upon
discovering a new node with a common family ID the node contacts the
matching node and uses the non-advertised family key in a handshake
(this could be a zero knowledge protocol like socialist millionaires
or just encrypting a concatenation of nodeIDs and nonces) to prove
that the key is shared.  After proving the secret is really shared the
nodes store the results and update their family advertisements.

This would simplify family configuration down to setting a single
common secret string per family but wouldn't create any change in
behaviour for non-family nodes and could also exist side by side with
the old mechanism.
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxxx with
unsubscribe or-talk    in the body. http://archives.seul.org/or/talk/