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.