Re: [tor-dev] Fact-checking a claim about relay/bridge fingerprint authentication

[Roger Dingledine <arma@xxxxxxxxxxxxxx>]

On Sat, Feb 10, 2024 at 12:15:05AM -0700, David Fifield wrote:
> The Snowflake paper has been conditionally accepted to Usenix Security
> and we are now working on final revisions.

Congrats! This is great!

> If possible, we'd still like confirmation of (1) whether this is a good
> characterization of the constraints involved when using a Tor bridge,
> and (2) if 4.2 is the right part of tor-spec to cite for clients
> disconnecting on an unexpected relay fingerprint.
> 
> https://github.com/turfed/snowflake-paper/blob/7181a5cdfe1e07cfb4ea6bc15c07d69cd793e908/snowflake.tex#L2396
> 	A Tor bridge is identified by a long-term identity public key.
> 	If, on connecting to a bridge, the client finds that the
> 	bridge's identity is not the expected one, the client will
> 	terminate the connection \cite[\S 4.2]{tor-spec}. The Tor client
> 	can configure at most one identity per bridge; there is no way
> 	to indicate (with a certificate, for example) that multiple
> 	identities should be considered equivalent. This constraint
> 	leaves two options: either all Snowflake bridges must share the
> 	same cryptographic identity, or else it must be the client that
> 	makes the choice of what bridge to use. While the former option
> 	is possible to do (by synchronizing identity keys across
> 	servers), every added bridge would increase the risk of
> 	compromising the all-important identity keys. Our vision was
> 	that different bridge sites would run in different locations
> 	with their own management teams, and that any compromise of a
> 	bridge site should affect that site only

This all sounds reasonable to me.

The phrase "all-important identity keys" made me pause, because in the
obfs4 bridgedb case, it doesn't matter so much that the client checks
the identity key, (a) because it's only one hop in the circuit, and
the client will still check the identities for the other relays in the
circuit, and (b) because it isn't all that meaningful to verify that it
really is the stranger we picked for you at random -- so long as whoever
it is extends your circuit to the relay you picked, and you verify that,
you're getting most of what you can get.

Whereas for the Snowflake case, checking the identity key on the bridge
is much more meaningful, first because we do actually know the bridge
operator and we want to make sure you reached the real one, but more
importantly because the Snowflake architecture puts the 'random stranger'
in exactly the position to send you somewhere else if it wants.

So yes, sounds good.

As for which part of tor-spec to cite, note that Nick and others did a
big reorg of tor-spec some months ago. It looks like 4.2 is from what
used to be path-spec.txt, which is about how we choose paths. If I were
to pick a piece of tor-spec to show that Tor clients decline to continue
if the first hop they've picked can't prove it knows its identity key,
I would pick section 2.3.1,
https://spec.torproject.org/tor-spec/negotiating-channels.html#negotiating
and the action is in the CERTS and AUTHENTICATE cells.

(For extra fun, I don't think anything promises that "2.3.1" will still
be the number of this section in the future.)

--Roger

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