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