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

[David Fifield <david@xxxxxxxxxxxxxxx>]

The Snowflake paper has been conditionally accepted to Usenix Security
and we are now working on final revisions. As before, no response is
necessary, but if you have any comments, we can try to take them into
account up until about 2024-02-26. This is a current snapshot:
https://www.bamsoftware.com/papers/snowflake/snowflake.20240210.7181a5cd.pdf

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

On Tue, Oct 03, 2023 at 08:44:39PM -0400, David Fifield wrote:
> Cecylia, Arlo, Serene, Shelikhoo, and I are writing a research paper
> about Snowflake. Here is a draft:
> https://www.bamsoftware.com/papers/snowflake/snowflake.20231003.e6e1c30d.pdf
> 
> We're writing to check a factual claim in the section about having
> multiple backend bridges. Basically, we wanted it to be possible for
> there to be multiple Snowflake bridge sites run by different groups of
> people, and we did not want to share the same relay identity keys across
> all bridge sites, because of the increased risk of the keys being
> exposed. Therefore every bridge site has its own relay identity, which
> requires the client to know the relay fingerprints in advance and that
> it be the client (and not, e.g., the broker) that decides which bridge
> to use.
> 
> 1. Is our general description (quoted below) of the design constraints
>    as they bear on Tor correct?
> 2. Is §4.2 "CERTS cells" the right part of tor-spec to cite to make our
>    point?
>    https://gitlab.torproject.org/tpo/core/torspec/-/blob/b345ca044131b2eb18e6ae0d5f23643a92aeff34/tor-spec.txt#L707
> 
> https://github.com/turfed/snowflake-paper/blob/e6e1c30dde6716dc5e54a32f2134f19068a7f395/snowflake.tex#L2146
> 	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.
> 
> In my own experiments, providing an incorrect relay fingerprint leads to
> errors in connection_or_client_learned_peer_id:
> https://gitlab.torproject.org/tpo/core/tor/-/blob/tor-0.4.7.13/src/core/or/connection_or.c#L1897
> [warn] Tried connecting to router at 192.0.2.3:80 ID=<none> RSA_ID=2B280B23E1107BB62ABFC40DDCC8824814F80A71, but RSA + ed25519 identity keys were not as expected: wanted 1111111111111111111111111111111111111111 + no ed25519 key but got 2B280B23E1107BB62ABFC40DDCC8824814F80A72 + 1zOHpg+FxqQfi/6jDLtCpHHqBTH8gjYmCKXkus1D5Ko.
> [warn] Problem bootstrapping. Stuck at 14% (handshake): Handshaking with a relay. (Unexpected identity in router certificate; IDENTITY; count 1; recommendation warn; host 1111111111111111111111111111111111111111 at 192.0.2.3:80)
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev