[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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



On Thu, Feb 15, 2024 at 10:54:22AM -0500, Roger Dingledine wrote:
> > 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.

Thanks for checking.

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

Okay, that makes sense. What's now section 2.3.1 is the same
"Negotiating and initializing connections/channels" as what was
section 4 in the txt version we were referring to initially. So it looks
like we did have the right part of the spec.
https://gitlab.torproject.org/tpo/core/torspec/-/blob/29e445bd6e9efe82367b8a2b09a6c6aa0bc92b7b/spec/tor-spec/negotiating-channels.md
https://gitlab.torproject.org/tpo/core/torspec/-/blob/33308845cec54bfc0096b8ea0339a8ff183aa1b1/tor-spec.txt#L622

The new mdbook style makes it a little harder to refer to a specific
section. Since this is the only reference to tor-spec we have, I guess
what we'll do is change the bib entry to refer to the .md file of just
this section, with a GitLab permalink.

Is `author = {Roger Dingledine and Nick Mathewson}` still appropriate?
That was the authorship on tor-spec.txt, but the new .md doesn't have
it. Would `author = {{The Tor Project}}` be better?
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev