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

[Roger Dingledine <arma@xxxxxxxxxxxxxx>]

On Wed, Jun 28, 2023 at 02:09:34AM -0600, David Fifield wrote:
> 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.

Makes sense.

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

Right. But that window where the cached version protects you is quite
narrow -- it looks like modern clients fetch a new bridge descriptor
every TestingBridgeDownloadInitialDelay (3 hours) (see where we set
next_attempt_at in learned_bridge_descriptor()), and not too long ago
we fetched a fresh bridge descriptor hourly.

The reasoning for the frequent fetches is that fetching the bridge's
descriptor over a one-hop circuit is a low cost operation, and it doubles
as a crude liveness check (since if it succeeds, the bridge should work
for real circuits too, and if it fails, we should mark the bridge as
not working currently).

When Tor starts up with a cached bridge descriptor with a timestamp we like,
I imagine it is not long until we attempt to fetch a fresh descriptor. I
haven't checked our current behavior though. But I would not rely on
this onion key caching for security.

Hope this helps!
--Roger

_______________________________________________
tor-relays mailing list
tor-relays@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays