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

[David Fifield]

On Thu, Jun 01, 2023 at 01:21:30PM -0400, Roger Dingledine wrote:
> 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.

Thanks, that was a subtlety I had missed. Since we are writing about
bridges, I mostly want to give the bridge perspective. We had formerly
written this:
	A relay's current onion keys appear in the Tor network
	consensus; when clients make circuits through it, they expect it
	to use certain onion keys.
We've now changed it to:
	Tor clients cache a bridge's onion public keys when they
	connect; subsequent connections only work if the cached keys are
	among the bridge's two most recently used sets of onion keys.

Here's my old post when I tested what would happen if a client cached
one onion key on the first attempt and then the onion key was not the
same on the second attempt:
https://lists.torproject.org/pipermail/tor-relays/2022-January/020238.html

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

So it sounds like compromise of an onion key is no worse than compromise
of an identity key, because with an identity key an attacker could cook
up and sign a new onion key. The exception is that if an attacker
somehow got an identity key but not current onion keys, and it's a
bridge that's affected rather than a relay, then the attacker would not
be able to fool clients that had previously connected and cached the
past genuine onion keys.