[tor-bugs] #18319 [Core Tor/Tor]: Exclude relays that don't match pinned RSA/Ed key pairs

Tor Bug Tracker & Wiki blackhole at torproject.org
Tue Nov 1 13:07:19 UTC 2016


#18319: Exclude relays that don't match pinned RSA/Ed key pairs
-------------------------------------------------+-------------------------
 Reporter:  teor                                 |          Owner:  andrea
     Type:  defect                               |         Status:
                                                 |  assigned
 Priority:  High                                 |      Milestone:  Tor:
                                                 |  0.3.0.x-final
Component:  Core Tor/Tor                         |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  tor-ed25519-proto, nickm-            |  Actual Points:
  deferred-20160905                              |
Parent ID:                                       |         Points:  1
 Reviewer:                                       |        Sponsor:
                                                 |  SponsorU-can
-------------------------------------------------+-------------------------

Comment (by nickm):

 Replying to [comment:23 teor]:
 > Replying to [comment:19 nickm]:
 > > ...
 > >
 > > When we turn on pinning, the most recent journal entry will rule.  So
 a relay will only be excluded from the consensus if its most recently
 pinned Ed25519 key is not the one it uses.  So if somebody switched Ed
 keys once a few months ago, they won't get penalized here.  This only
 affects them if they are switching frequently, or if they switch keys
 again.
 > >
 > > The rule for relays becomes:
 > > {{{
 > > Always use the same Ed25519 identity with the same RSA identity.
 > > }}}
 > > So, don't switch one unless you also switch the other.  If you lose
 one, don't try to retain the other.
 > >
 > > Sebastian says:
 > > > ...
 > > > How will this all work, by the way? My key pinning journal goes back
 one year and has more entries than what is written above, including more
 than just the dirauth above.
 > >
 > > Once key pinning is turned on, an authority will believe the latest
 entry for any given RSA key.  They will not accept a descriptor signed
 with that RSA identity key unless it also has the provided Ed25519
 identity.  So it only affects the voting, not the consensus.
 > > ...
 >
 > I see from the manual that AuthDirPinKeys is set on a per-authority
 basis, so it only affects that authority's votes (and so it's not like a
 consensus method, where every authority uses it at the same time).
 >
 > '''Activation Timing'''
 >
 > What if I run a relay that changes ed keys during the changeover?
 >
 > If authorities A, B, C, D set key pinning at hour 1,
 >  & authorities E, F, G, H set key pinning at hour 2,
 > then I have a different ed key pinned on some authorities compared to
 others.
 >
 > I guess I need to regenerate both RSA & ed keys in this instance.

 Yes.  If you are a relay, you should never keep one key and change the
 other.  The consequences for doing it during the changeover are weirder
 than usual.

 > '''Keeping State'''
 >
 > Will authorities need to back up their key pinning file?
 >
 > If an authority is restored with an empty pinning file, it will
 regenerate its key pinning file based on the descriptors it sees at that
 time, and those descriptors could be different after the restore. (But the
 other authorities will anchor the pinning, if a majority keep their
 files.)

 IMO authorities should probably back these up, but it isn't crucial.

 > '''Requiring Ed25519'''
 >
 > Also, what are we going to do about `DISABLE_DISABLING_ED25519`?
 > It's currently `#undef`, which means that a relay can drop its ed25519
 key whenever it wants.
 > When are we going to turn it on? When 0.2.5 is no longer recommended?


 That sounds plausible to me.  Or another option would be to look at
 historical metrics data to see how often relays run a recent version for a
 while, then drop back to an older one.  If the answer is "almost never"
 then we can just turn it on now.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/18319#comment:24>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list