[tor-relays] Security implications of disabling onion key rotation?

[David Fifield]

On Thu, Jun 01, 2023 at 09:07:17AM -0400, Nick Mathewson wrote:
> On Wed, May 24, 2023 at 8:54 PM David Fifield <david at bamsoftware.com> wrote:
> [...]
> >
> > What are the risks of not rotating onion keys? My understanding is that
> > rotation is meant to enhance forward security; i.e., limit how far back
> > in time past recorded connections can be attacked in the case of key
> > compromise. https://spec.torproject.org/tor-design Section 4 says:
> >         Short-term keys are rotated periodically and independently, to
> >         limit the impact of key compromise.
> 
> This is an interesting question!
> 
> So, compromising an onion key shouldn't be enough on its own to break
> forward secrecy.  The circuit extension handshakes use an additional
> set of ephemeral keys as part of the negotiation process, which are
> discarded immediately after the handshake.  (This is the
> diffie-hellman keys in TAP, and the x/X y/Y keypairs in ntor.)
> Assuming that this is done properly, and all the cryptographic
> assumptions hold, these keys alone should make it impossible to
> decrypt anything after the session keys are discarded.
> 
> The purpose of the onion key is, rather, to make it impossible for
> somebody else to impersonate the target relay.  If somebody steals
> your onion key, and they have their own relay R, then they can use
> your onion key to impersonate you whenever somebody tries to extend a
> circuit from R to you.
> 
> Onion key rotation limits the time range in which this kind of attack
> is useful: it will only work for as long as the onion key is listed in
> a live directory.
> 
> (Now, any attacker who can steal your onion key can probably also
> steal your identity key too, if you don't keep that offline, and use
> it to impersonate you for even longer. The advantage of using a stolen
> onion key is that it's much harder to detect; all the attacks I can
> think of that use a stolen identity key involve, whereas the
> onion-key-theft attack occurs when you are already in a perfect
> position to be a MITM.)

Thanks, that helps. If I understand correctly, compromise of an onion
key allows an attacker to impersonate the relay because it is
effectively the relay's "identity" as far as CREATE cells and
circuit_send_first_onion_skin are concerned; i.e., the public onion key
is the "B" in the ntor handshake, in which the relay's actual long-term
identity key doesn't play a role. The only way the identity keys figure
into it is that they (via the signing keys) sign the consensus documents
that inform clients what onion keys to expect.

The way I'm planning to summarize this is that, with onion key rotation
disabled, you need to treat the now long-term onion keys as if they were
long-term identity keys.