[tor-dev] Proposal 242: Better performance and usability for the MyFamily option

[l.m]

Hi,

If I understand the factors, as things stand currently, regarding
family use with respect to the *security* of Tor.

Pros
1 - Prevents information disclosure in case of using related relay too
much (relay configuration or seizure of hardware).

Cons
2 - It's not used by operators with malicious intent.
3 -  Reduces diversity in choosing non-malicious relay assuming all
relay in  a family have similar performance/bandwidth. If the metrics
vary widely  in the first place there's the chance it won't matter.
4 - Allows use of nickname and fingerprint.
5 - Can be used arbitrarily by unrelated nodes to influence path
selection.
6 - Clients already disobey family under non-deterministic
circumstance (not reliably reproduced but have measured)

The  proposed changes, in absence of any errata, are an improvement
for  enforcing a bidirectional relationship. For this reason it
mitigates (4), and (5). If arbitrary nodes cannot simply join a family
it also has less of an impact on (3) than when the tickets were
originally filed.

Towards mitigating (3) it might be worth considering the AS of the
related relays. I know  this increases computation cost so it's more
of a thought than even a  suggestion. If the AS differs across related
relay you might consider  this (honest?) operator a safe choice for
not setting the  family. That is that the family might be better based
on similarity of  AS, supposing that this would make it easier to
compromise usage data.  Another thought is to consider families as a
single node for the purpose  of computing network diversity. If a
situation occurs where diversity  is low it would be useful to not
consider families or to reconsider the  so-called safe-families. You
might call this a discussion towards relaxing family definition
(slightly) in favor of  increasing diversity, but staying within the
changes of Proposal 242.
--leeroy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150302/a941d0c6/attachment.html>