Re: [tor-dev] Proposal 247 (Hidden Service Vanguards) Overhaul and Proposal: Padding Negotiation
Tim Wilson-Brown - teor: > > > On 14 Sep 2015, at 09:07, Mike Perry > > wrote: > > > > ... > > > > > > 4. Security concerns and mitigations > > > > 4.1. Mitigating fingerprinting of new HS circuits > > > > By pinning the middle nodes of rendezvous circuits, we make it > > easier for all hops of the circuit to detect that they are part of > > a special hidden service circuit with varying degrees of certainty. > > > > ... > > > > The most serious of these is the Guard fingerprinting issue. When > > proposal xxx-padding-negotiation is implemented, services that > > enable this feature should use those padding primitives to create > > fake circuits to random middle nodes that are not their guards, in > > an attempt to look more like a client. > > How will this interact with the rate limiting in > xxx-padding-negotiation section 4.1? > > > On 12 Sep 2015, at 10:34, Mike Perry > > wrote: > > > > 4.1. Rate limiting > > > > ... > > > > We recommend that three consensus parameters be used in the event > > that the network is being overloaded from padding to such a degree > > that padding requests should be ignored: > > > > * CircuitPaddingMaxRatio - The maximum ratio of padding traffic to > > non-padding traffic (expressed as a percent) to allow on a circuit > > before ceasing to pad. Ex: 75 means 75 padding packets for every > > 100 non-padding packets. - Default: 100 * CircuitPaddingLimitCount > > - The number of padding cells that must be transmitted before the > > ratio limit is applied. - Default: 500 * CircuitPaddingLimitTime - > > The time period in seconds over which to count padding cells for > > application of the ratio limit. - Default: 60 > > > > XXX: Should we cap padding at these rates, or fully disable it once > > they're crossed? > > > If the rate limiting is being applied, that will limit fake middle > circuits (with few non-padding packets) to ~500 cells per minute > (~4KBytes per second). Hrmm.. More importantly, 500 cells is only roughly 250kb, and apparently the average webpage size has ballooned to up to 1.6M: http://www.websiteoptimization.com/speed/tweak/average-web-page/ I've boosted the default here to 5000, so we can give this case a chance at pretending to fetch web pages. > Does CircuitPaddingLimitCount reset after CircuitPaddingLimitTime? (I > can’t tell from the proposal, but I assume it has to reset, otherwise > the limit is quite low, at 500 cells per fake circuit for its entire > lifetime [plus whatever dribble it gets from non-padding cells].) The count is meant to reset after CircuitPaddingLimitTime. I've clarified this and pushed again to my padding_negotiation branch. > Are those consensus parameters intended to be always set, or just set > when there is an issue with padding? (I can see arguments both ways, > but having them always set could be useful as a precaution against a > quick attack.) The way consensus parameters work in the Tor client code is that they have a hardcoded default value that is used if they are not present in the consensus. If a consensus value is present, it overrides this hardcoded value. Hence it makes sense to set the defaults fairly liberally, and we'd only reduce them in the consensus if we noticed overload/abuse at relays. -- Mike Perry signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] . tor-roster's geo diversity badge and self-ref relays
We'll remove it. -V On Mon, 14 Sep 2015 at 05:20 Tom van der Woerdt wrote: > > On 13 Sep 2015, at 22:09, teor wrote: > > > On 13 Sep 2015, at 18:18, Sean Saito wrote: > > >"No Self-Referencing Relays" > > >I'm not sure what exactly you mean by that but I assume it is a MyFamily > > >config where a relay includes his own fingerprint. Why does that hurt? > > >The unnecessary descriptor space/bw? > > > > This is something Virgil wanted because he thought self-connections were > ugly. If the > > penalizing of self-connections is found to be uglier than the > self-connections themselves, we're > > both fine with removing it. > > > Can this be downgraded to an informational message? (or eliminated > entirely?) > > Penalties can be quite discouraging, particularly for minor configuration > variants. > > Tim > > > I agree, and this one in particular is important to some operators: by > allowing a relay to specify itself in the family, one can just have a > single configuration file for all relays in a family. > > Tom > > ___ > tor-dev mailing list > tor-dev@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal: Padding Negotiation
Tim Wilson-Brown - teor:
> Hi Mike,
>
> Just a few questions about the proposal, inline below:
>
> > On 12 Sep 2015, at 10:34, Mike Perry wrote:
> >
> > Here's a proposal describing some padding negotiation cell primitives that
> > should be useful to defend against website traffic fingerprinting, hidden
> > service circuit fingerprinting, and probably just about any other traffic
> > analysis attack under the sun.
> >
> > The proposal is in my git remote at:
> > https://gitweb.torproject.org/user/mikeperry/torspec.git/tree/proposals/xxx-padding-negotiation.txt?h=padding_negotiation
> >
> > ==
> >
> > Filename: xxx-padding-negotiation.txt
> > Title: Padding Negotiation
> > Authors: Mike Perry
> > Created: 01 September 2015
> > Status: Draft
> >
> >
> > ...
> >
> >
> > 3. End-to-end circuit padding
> >
> > For circuit-level padding, we need two types of additional features: the
> > ability to schedule additional incoming cells at one or more fixed
> > points in the future, and the ability to schedule a statistical
> > distribution of arbitrary padding to overlay on top of non-padding
> > traffic (aka "Adaptive Padding").
> >
> > In both cases, these messages will be sent from clients to middle nodes
> > using the "leaky pipe" property of the 'recognized' field of RELAY
> > cells, allowing padding to originate from middle nodes on a circuit in a
> > way that is not detectable from the Guard node.
> >
> > This same mechanism can also be used to request padding from the Guard
> > node itself, to achieve link-level padding without the additional
> > overhead requirements on middle nodes.
> >
> > 3.1. Fixed-schedule padding message (RELAY_COMMAND_PADDING_SCHEDULE)
> >
> > The fixed schedule padding will be encoded in a
> > RELAY_COMMAND_PADDING_SCHEDULE cell. It specifies a set of up to 80
> > fixed time points in the future to send cells.
>
> Do we want to add a length field, for schedules with less than 80 time points?
> Or is this unnecessary?
At first, I thought this was unnecessary, as it is completely acceptable
to leave unused fields as 0s in my definition. Since Trunnel should make
working with variable fields more safe and less cumbersome, I've
simplified this to use variable lengths.
> > XXX: 80 timers is a lot to allow every client to create. We may want to
> > have something that checks this structure to ensure it actually
> > schedules no more than N in practice, until we figure out how to
> > optimize either libevent or timer scheduling/packet delivery. See also
> > Section 4.3.
> >
> > The RELAY_COMMAND_PADDING_SCHEDULE body is specified in Trunnel as
> > follows:
> >
> >struct relay_padding_schedule {
> > /* Number of microseconds before sending cells (cumulative) */
> > u32 when_send[80];
> >
> > /* Number of cells to send at time point sum(when_send[0..i]) */
> > u16 num_cells[80];
> >
> > /* Adaptivity: If 1, and server-originating cells arrive before the
> > next when_send time, then decrement the next non-zero when_send
> > index, so we don't send a padding cell then, too */
> > u8 adaptive IN [0,1];
>
> Is this the definition of “adaptivity" that we want?
>
> I can see that it works in the scenario where a client wants a minimum of
> X cells delivered at-or-before time T (adaptively), where T is a single
> schedule
> arbitrarily far in the future.
This cell is meant to request a one-shot amount of padding, not a
periodic cycle. Anything periodic like this should use Adaptive padding.
> But if a client wants a minimum of X cells delivered every T microseconds
> (adaptively), then there’s no way to reliably specify that using this scheme.
> If
> 10*X cells originate at the server due to regular traffic in the first
> interval, that will
> cause the next 10 intervals to be skipped.
>
> I can see that the histograms work around this issue by refilling with the
> original
> figures, but I’m not sure that works for fixed-point padding.
I believe that we should ensure that the Adaptive Padding machine can
specify this and any other type of periodic padding. If it can't, we
should generalize it further, not add another primitive for specifying
periodic padding.
In fact, I've pushed updates to the adaptive padding rules in order to
allow three different versions of what you've asked, and provided the
example machine specifications for these examples. Please let me know if
you feel that we still need further flexibility to cover another related
example. You probably want a pen and paper handy to draw the state
machines and their transitions out as you read through the rules.
Example 1: X cells delivered over T microseconds, spread evenly. If a
non-padding cell is sent, padding is skipped for the next T/X
microseconds.
num_machines = 1;
machines[0].transition_burst_events = 0;
machines[0].burst.histogram_len = 2;
machines[0].burst.histogram = {1, 0};
machines[0].burst.trans
Re: [tor-dev] Proposal 247 (Hidden Service Vanguards) Overhaul and Proposal: Padding Negotiation
> On 14 Sep 2015, at 09:07, Mike Perry wrote: > > ... > > > 4. Security concerns and mitigations > > 4.1. Mitigating fingerprinting of new HS circuits > > By pinning the middle nodes of rendezvous circuits, we make it > easier for all hops of the circuit to detect that they are part of a > special hidden service circuit with varying degrees of certainty. > > ... > > The most serious of these is the Guard fingerprinting issue. When > proposal xxx-padding-negotiation is implemented, services that enable > this feature should use those padding primitives to create fake circuits > to random middle nodes that are not their guards, in an attempt to look > more like a client. How will this interact with the rate limiting in xxx-padding-negotiation section 4.1? > On 12 Sep 2015, at 10:34, Mike Perry wrote: > > 4.1. Rate limiting > > ... > > We recommend that three consensus parameters be used in the event that > the network is being overloaded from padding to such a degree that > padding requests should be ignored: > > * CircuitPaddingMaxRatio >- The maximum ratio of padding traffic to non-padding traffic > (expressed as a percent) to allow on a circuit before ceasing > to pad. Ex: 75 means 75 padding packets for every 100 non-padding > packets. >- Default: 100 > * CircuitPaddingLimitCount >- The number of padding cells that must be transmitted before the > ratio limit is applied. >- Default: 500 > * CircuitPaddingLimitTime >- The time period in seconds over which to count padding cells for > application of the ratio limit. >- Default: 60 > > XXX: Should we cap padding at these rates, or fully disable it once > they're crossed? If the rate limiting is being applied, that will limit fake middle circuits (with few non-padding packets) to ~500 cells per minute (~4KBytes per second). Does CircuitPaddingLimitCount reset after CircuitPaddingLimitTime? (I can’t tell from the proposal, but I assume it has to reset, otherwise the limit is quite low, at 500 cells per fake circuit for its entire lifetime [plus whatever dribble it gets from non-padding cells].) Are those consensus parameters intended to be always set, or just set when there is an issue with padding? (I can see arguments both ways, but having them always set could be useful as a precaution against a quick attack.) Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP: 968F094B (ABFED1AC & A39A9058 expire 15 Sep 2015) teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F (From 1 Sep 2015) signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Bridge Guards (prop#188) & Bridge ORPort Reachability Tests
> On 12 Sep 2015, at 17:26, isis wrote: > > ... > > However, for "double onion services" — or whatever we're calling the thing > that > is (historical) hidden services 2.0 — your point is a good one; I'm starting > to > realise more and more that defences for "double onion services"¹ are possibly > defences for bridges and vice versa. > > ... > > ¹ Sorry, but — after having to type that twice — that name sucks. “double onion services” - I see what you mean. What about “dual onion services”? Or even “dual onion”? It’s shorter, and means the same thing. I’ll stop bikeshedding now. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP: 968F094B (ABFED1AC & A39A9058 expire 15 Sep 2015) teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F (From 1 Sep 2015) signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Proposal 247 (Hidden Service Vanguards) Overhaul
I spent some time trying to clean up proposal 247 based on everyone's
comments, as well as based on my own thoughts. Please have a look if you
commented on the original proposal, and complain if I've not taken your
thoughts into account.
(Aaron: In particular, I made several tradeoffs in favor of performance
and DoS resistance that may be at odds with some of your suggestions,
but I think the end result is still OK after looking into the Sybil
rates and thinking about the adversary model in more detail. You may
disagree).
I've attached my updated version of the proposal inline in this mail,
but the canonical updated proposal is in my remote at:
https://gitweb.torproject.org/user/mikeperry/torspec.git/tree/proposals/247-hs-guard-discovery.txt?h=guard_discovery_dev
Here's a summary of the changes (which are also listed in Git):
* Try to make a coherent threat model and specify its assumptions
* Fold in my comments about using disjoint sets ("buckets") for the
third level guard.
* Make the parameter discussion subsection its own section, and include
tables with far more detail for the Sybil success rates.
* Put the rotation period in a separate subsection from the number of
guards
* Switch to using min(X,X) and max(X,X) for the distribution for the
second and third layer guard lifespans, respectively. Add a
subsection describing this distribution (3.2.3)
* Changed the default parameters based on these tables, and based on my own
intuition about Tor's performance properties.
* Move the load balancing, torrc, and other performance considerations to
their own section (Section 5).
* Move "3.2. Distinguishing new HS circuits from normal HS circuits" to
section 4.1.
* Fold in some of "3.3. Circuit nodes can now be linked to specific hidden
services" into 4.1. Some of it I just removed, though, because I did not
find it credible.
* Added Roger's concerns about guard linkability to Section 4.2.
* Added a denial of service subsection to Section 4.3.
Filename: 247-hs-guard-discovery.txt
Title: Defending Against Guard Discovery Attacks using Vanguards
Author: George Kadianakis
Created: 2015-07-10
Status: Draft
0. Motivation
A guard discovery attack allow attackers to determine the guard
node of a Tor client. The hidden service rendezvous protocol
provides an attack vector for a guard discovery attack since anyone
can force an HS to construct a 3-hop circuit to a relay (#9001).
Following the guard discovery attack with a compromise and/or
coercion of the guard node can lead to the deanonymization of a
hidden service.
1. Overview
This document tries to make the above guard discovery + compromise
attack harder to launch. It introduces an optional configuration
option which makes the hidden service also pin the second and third
hops of its circuits for a longer duration.
With this new path selection, we force the adversary to perform a
Sybil attack and two compromise attacks before succeeding. This is
an improvement over the current state where the Sybil attack is
trivial to pull off, and only a single compromise attack is required.
With this new path selection, an attacker is forced to do a one or
more node compromise attacks before learning the guard node of a hidden
service. This increases the uncertainty of the attacker, since
compromise attacks are costly and potentially detectable, so an
attacker will have to think twice before beginning a chain of node
compromise attacks that he might not be able to complete.
1.1. Visuals
Here is how a hidden service rendezvous circuit currently looks like:
-> middle_1 -> middle_A
-> middle_2 -> middle_B
-> middle_3 -> middle_C
-> middle_4 -> middle_D
HS -> guard -> middle_5 -> middle_E -> Rendezvous Point
-> middle_6 -> middle_F
-> middle_7 -> middle_G
-> middle_8 -> middle_H
-> ...-> ...
-> middle_n -> middle_n
this proposal pins the two middles nodes to a much more restricted
set, as follows:
-> guard_3A_A
-> guard_2_A -> guard_3A_B
-> guard_3A_C -> Rendezvous Point
HS -> guard_1
-> guard_3B_D
-> guard_2_B -> guard_3B_E
-> guard_3B_F -> Rendezvous Point
Note that the third level guards are partitioned into buckets such that
they are only used with one specific second-level guard. In this way,
we ensure that even if an adversary is able to execute a Sybil attack
against the third layer, they only get to learn one of the second-layer
Guards, and not all of them. This prevents the adversary from gaining
the ability to take their pick
Re: [tor-dev] . tor-roster's geo diversity badge and self-ref relays
> On 13 Sep 2015, at 22:09, teor wrote: > > >> On 13 Sep 2015, at 18:18, Sean Saito wrote: >> >> >"No Self-Referencing Relays" >> >> >I'm not sure what exactly you mean by that but I assume it is a MyFamily >> >> >config where a relay includes his own fingerprint. Why does that hurt? >> >> >The unnecessary descriptor space/bw? >> >> >> >> This is something Virgil wanted because he thought self-connections were >> ugly. If the >> >> penalizing of self-connections is found to be uglier than the >> self-connections themselves, we're >> >> both fine with removing it. >> > > Can this be downgraded to an informational message? (or eliminated entirely?) > > Penalties can be quite discouraging, particularly for minor configuration > variants. > > Tim I agree, and this one in particular is important to some operators: by allowing a relay to specify itself in the family, one can just have a single configuration file for all relays in a family. Tom ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] . tor-roster's geo diversity badge and self-ref relays
> On 13 Sep 2015, at 18:18, Sean Saito wrote: > > >"No Self-Referencing Relays" > > >I'm not sure what exactly you mean by that but I assume it is a MyFamily > > >config where a relay includes his own fingerprint. Why does that hurt? > > >The unnecessary descriptor space/bw? > > > > This is something Virgil wanted because he thought self-connections were > ugly. If the > > penalizing of self-connections is found to be uglier than the > self-connections themselves, we're > > both fine with removing it. > Can this be downgraded to an informational message? (or eliminated entirely?) Penalties can be quite discouraging, particularly for minor configuration variants. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Let's identify which measurement-related tools need work when relays switch from RSA identities to ed25519 identities
> It's true, dropping the fingerprint is quite invasive and might break > things. But that's why we're making plans now to make this transition > as smooth as possible. > > However, I don't think that we can get away by just replacing the > existing 20 byte long RSA key digest with a 20 byte long hash of the > new, 32 byte long ed25519 key. There are probably cryptographic > reasons for that. But in addition to that, there should be a time > when relays use both fingerprints in parallel so that directory > authorities and other tools can build a map from old to new > identities. Otherwise, relays would lose all their history only > because they are switching from RSA to ed25519, and wouldn't that be > sad? There might be more reasons that I'm currently not thinking of. > But: I'm not making this call, I'm just thinking about the possible > impact of this change and which code needs to be updated. > > How about we talk more about this in Berlin together with Nick? Maybe > take a look at the list I wrote and think of other code that will need > work when this change actually takes place? Certainly, sounds good! For what it's worth my concern is about the fingerprint's longstanding role as the relay identifier. Some spots off the top of my head... * The control spec allows you to query descriptors by fingerprint or nickname. * Circuit events and most other things citing relays do so by fingerprint or fingerprint~nickname. * Atlas, Globe, and just about every tool that allows you to look up relay information does so by fingerprint. * In Stem anything related to identifying a relay does so by fingerprint. No doubt there's many, many other things that'll break too. This is the main identifier of a relay and I'd expect mucking with it to break all the things. Hence my interest in an in-place replacement instead. ;) Cheers! -Damian ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Let's identify which measurement-related tools need work when relays switch from RSA identities to ed25519 identities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/09/15 18:16, Damian Johnson wrote: >>> Hi Karsten. Quick question: with the switchover are relay >>> fingerprints going away? That is to say, server descriptors no >>> longer have a... >>> >>> fingerprint D203 4DDF 1275 A234 4F66 9935 A3EF B908 FFC7 AE9A >>> >>> ... line, and router status entries don't have it on their >>> dir-source? > If not, what in particular are being dropped? >>> >>> Cheers! -Damian >> >> yes, I think that's the plan. Please see proposal 220, Sections >> 8 and 9 for some more details. > > Thanks Karsten. Now that I know this isn't a completely foolish > question adding tor-dev@ back in. > > If we're dropping the fingerprint that's a lot more invasive. > Fingerprints are relay's canonical identity, and simply dropping > them will break... a lot. I'd suggest instead relays should > continue to have a fingerprint but that it's the 40 character hex > hash of the ed25519 identity. It's true, dropping the fingerprint is quite invasive and might break things. But that's why we're making plans now to make this transition as smooth as possible. However, I don't think that we can get away by just replacing the existing 20 byte long RSA key digest with a 20 byte long hash of the new, 32 byte long ed25519 key. There are probably cryptographic reasons for that. But in addition to that, there should be a time when relays use both fingerprints in parallel so that directory authorities and other tools can build a map from old to new identities. Otherwise, relays would lose all their history only because they are switching from RSA to ed25519, and wouldn't that be sad? There might be more reasons that I'm currently not thinking of. But: I'm not making this call, I'm just thinking about the possible impact of this change and which code needs to be updated. How about we talk more about this in Berlin together with Nick? Maybe take a look at the list I wrote and think of other code that will need work when this change actually takes place? All the best, Karsten > On a side note it would be nice to have a spec patch before > changing things this time. Sections 8 and 9 are a fine summary, but > it's not clear to me precisely how the descriptors are changing > from it. They certainly don't say to me "we're dropping the > fingerprint field". If that change went out without a spec patch > first I'd borrow Mr. Potato Head's angry eyes to stare at its > author. > > Cheers! -Damian ___ > tor-dev mailing list tor-dev@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJV9YYpAAoJEJD5dJfVqbCr5bQIAMDFa02wnrxpL+qCiXBHCJ+g RAIZHgKWOUSO35dAyLDpDbnRWLbTMOlXgxrdbBNLzzXrs+9jT9Ivz2ZEHPnSwt88 P0f396ZU/QvpT4M4uZXLV/Nzq0S1+OqjK/brDXMNwZaKuJKF8rjtvJvVb4s1HQVD ubf8EV1vz4/7XS+yPKanZWdnFnBTCsT/56D0pcEyntk3evLElJCeC1f5fMXkrzLO Iu8ZfRoNgAMJ7EbKH6SucyExpsY0xfSOSl+E06ZVYH20AuT/ZBT88S/Yqv0vTduW vY10tSrigm5/UsoCV5sTNG/DMq5F19MPfYts7N05NM5iOEFIkIulD1AOPBhVj34= =nWI2 -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] . tor-roster's geo diversity badge and self-ref relays
Hi nusenu, >Do you consider in-family diversity so important - even though all of >them are run by a single entity anyway? > How about having a badge for tor network wide diversity? > I'd consider the tor network's overall diversity far more important than > in-family diversity because clients won't use more than one relay of a > given family anyway. Entire-network diversity is obviously more important than within-operator diversity---no doubt about that. We are doing within-operator diversity simply because the it's easier to measure/understand. I agree that measuring a family's relay diversity with respect to the entire Tor network is would be supplementary, maybe even strictly better. I am already logging relevant data, namely the number of relays per country and total CW per country (as you suggested previously). The former stastic could be used for badges like "First relay in country X." >More than 4/5 of the family's CW is located in countries with a cw lower >than 2%* (currently means non-top 7 country) and ASes lower than 1.5%* >(currently means non-top 8 AS)? > >That implies some degree of in-family diversity since a big family would >have to spread across multiple countries/ASes Although there have been some interesting discussions about which ASes to prioritize in putting new relays, an actual concrete numerical measure is thus far an unsolved problem. Virgil and I have talked about using a new tool (http://labs.apnic.net/vizas/) to observe which ASes have more interconnections and award bonus points to new relays on them. When these measures become better established definitely in favor of making badges for them (perhaps even replacing the within-operator diversity badges?). >"No Self-Referencing Relays" >I'm not sure what exactly you mean by that but I assume it is a MyFamily >config where a relay includes his own fingerprint. Why does that hurt? >The unnecessary descriptor space/bw? This is something Virgil wanted because he thought self-connections were ugly. If the penalizing of self-connections is found to be uglier than the self-connections themselves, we're both fine with removing it. Hope this answers your questions. Thanks for the feedback! Best, Sean ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
