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

[Roger Dingledine]

Thanks Nick! I endorse Nick's response, with two additions:

On Thu, Jun 01, 2023 at 09:07:17AM -0400, Nick Mathewson wrote:
> 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.

For bridges it is a little bit different, because bridges don't have
an onion key listed in any public (consensus style) directory document
that clients get. Rather, the client connects to the bridge directly and
fetches a full timestamped descriptor from the bridge, which is signed
by the bridge's identity key, and which includes the onion key that the
client should use.

So if you have broken an old (rotated) onion key for a bridge, the
proper attack involves MITMing the connection to the bridge, breaking
or stealing the bridge's identity key too, and crafting a new descriptor
that lists the old onion key.

Whereas if the bridge never rotates the onion key, then you would be
able to successfully attack the CREATE cell that the client sends to
the bridge -- but only if you could see it, which would involve MITMing
the connection to the bridge and also being able to convince the client
that you are the bridge, which I think implies having or breaking the
identity key too. Doesn't seem so bad.

> (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.)

"...involve publishing a new signed document which others could notice"
maybe?

Though for the bridge case, the attack could be more subtle, in that you
could provide a specially signed descriptor only to your victim user,
who would then learn the special onion key from that descriptor, use it,
and never know that other users received a different descriptor.

An attack like that isn't so bad though, because we still have the second
hop and third hop in the circuit, producing their own forward-secret
session keys with their own properly rotated onion keys, and having the
protections that Nick describes.

--Roger