[tor-relays] Giving away some "pre-warmed" relay keys for adoption

[Yawning Angel]

On Sun, 26 Jul 2015 05:32:17 +0500
Roman Mamedov <rm at romanrm.net> wrote:

> On Sat, 25 Jul 2015 19:47:23 +0000
> isis <isis at torproject.org> wrote:
> 
> > I could take those backdoored^W"pre-warmed" keys and put them to
> > good use!
> 
> Hello,
> 
> Mkay, I'll get in touch in a few days.
> 
> As for other repliers, I would not mind explaining my reasoning in
> more detail, if you have any specific questions or more articulated
> objections that a knee-jerk "ban it" or "lolz" reactions.

What was knee-jerk about my response?

The relay identity key is sensitive cryptographic material.  Sharing it
means the private key is compromised and is an attempt to subvert:

 * The bandwidth scanning process.  The consensus weight is the relay's
   capacity relative to other nodes in the network which will change
   and should be reset if the location of the relay changes.

   Yes, in an ideal world the bwauths will scan new relays faster.  But
   that's orthogonal to the need to reset/remeasure on IP address
   change.

 * The flag assignment process.  A random person should not get the
   Guard or Stable flag quickly.

The only thing a compromised relay should be used for is as a middle
node and never a HSDir, so the correct behavior on the DirAuth side is
to never assign the Valid flag to said relays.

A fun task for someone who likes messing with consensus documents and
descriptors would be to write a script to measure IP address churn
for relays while the relay identity remains constant (either
legitimately eg: being on a dynamic IP, person had to move the rack the
relay was on, or through key compromise/derp).

I'm of the opinion that it may be worth adding code to pin relay
identities to IP addresses on the DirAuth side so that consensus weight
and flag assignment gets totally reset if the ORPort IP changes, but if
there's too much churn already it may cause more trouble than it's
worth.

Regards,

-- 
Yawning Angel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20150726/13f7538c/attachment.sig>