A Simple Web of Trust for Relay Operator IDs

changed title from Simple Web of Trust for Relay Operator IDs to A Simple Web of Trust for Relay Operator IDs

requested review from @dgoulet

changed the description

So couple things right off the bat. I did a pass on the proposal and I'm having trouble to see where "tor" comes into play here in terms of protocol?

What needs to be done by a tor node (client, relay, authority, ...) and do we need something to change on anything exposed in the directory documents?

So couple things right off the bat. I did a pass on the proposal and I'm having trouble to see where "tor" comes into play here in terms of protocol?

The document has a narrow scope: This spec only defines how trust information is published, retrieved and validated. It does not mandate how trust information must be used.

Roger's idea to use trust information to split network capacity into known and unknown groups and to limit the fraction of capacity by unknown operators is related https://lists.torproject.org/pipermail/tor-relays/2020-July/018656.html but outside the scope of this spec.

What needs to be done by a tor node (client, relay, authority, ...) and do we need something to change on anything exposed in the directory documents?

No change to directory documents is required at this point.

Next steps for this as I see them:

Move the proposal to a "well-known.txt" file in the root of the torspec repo.
Add a new /well-known to https://spec.torproject.org/
Update the IANA registry to point at the above URL

Iain Learmonth (@irl):

Iain Learmonth commented:

Next steps for this as I see them:

Move the proposal to a "well-known.txt" file in the root of the torspec repo.

Add a new /well-known to https://spec.torproject.org/

Update the IANA registry to point at the above URL

I am not convinced yet the proposal should be on spec.torproject.org. Maybe we should create some other place for network health related ideas?

Move the proposal to a "well-known.txt" file in the root of the torspec repo.

Add a new /well-known to https://spec.torproject.org/

Update the IANA registry to point at the above URL

just to avoid confusions: the files in this spec that are placed under the "tor-relay" well-known URI will go into the related spec at some point (maybe in the same branch/merge):

https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/326-tor-relay-well-known-uri-rfc8615.md

I'm going for now to transfer this to @gk until we figure this out. IF the consensus ends up being that torspec.git is the right place, just put me back as Reviewer. Thanks!

requested review from @gk and removed review request for @dgoulet

assigned to @nusenu

I hope this is appropriate to respond here. I realize there is debate about where the proposal/issue/spec/? should live. (I will continue to say 'proposal' for now for simplicity).

The general approach is quite related to what we have been calling self-authenticating traditional addresses (SATAs). Developing those has been focused on use for securely accessing websites, rather than selecting trusted relays for Tor circuits. But they should be applicable to relays and offer advantages over the proposal in its current form. For an overview of the most recent design and implementation see especially the appendix of "Attacks on Onion Discovery and Remedies via Self-Authenticating Traditional Addresses" https://arxiv.org/abs/2110.03168 There are links to other documents, code on github, etc. therein.

I would be happy to contribute to updating this proposal to incorporate SATAs. Why use SATAs? A sample of the reasons, include

Already makes use of the [self-authenticating-key].example.com format and has existing client and server code that can be leveraged for this. Note: The [self-authenticating-key] in SATAs to date has been an onion address not a relay identifier. Likewise it has generally been intended that typically there is a single self-authenticating key per domain and vice versa, but that is not required.
Does not depend directly on DNS or DNSSEC, thus avoids associated issues and limitations of relying on these.
WRT concern about handing out different trust information to different people and suggestion to create a public append-only log. SATAs are included in TLS certificates. Thus they are already verifiable as included in CT logs. (And we are separately at work on further leveraging that.)
Sattestations are (at minimum) attestations that an onion address and domain name in a SATA are under the control of a single entity. Call that 'intact'. Sattestation labels (also already implemented) provide a natural way to support trust anchors for sets of labels. E.g., a trusted sattestor could say that a set of relay-SATAs are each intact and labeled to be in a particular family, or separately get a label saying 'trusted by this sattestor'---meaning trusted for route selection, which is distinct from being validated by this sattestor to be intact. Even without trusted-third-party sattestation, binding multiple identifiers to the same domain name via inclusion as SANs in the same certificate is a straightforward way to express family.

Could say lots more but will limit to this for now.

Hi @syverson,

thanks for your input.

For an overview of the most recent design and implementation see especially the appendix of "Attacks on Onion Discovery and Remedies via Self-Authenticating Traditional Addresses" https://arxiv.org/abs/2110.03168

I had a look at that paper and ref [21] which I found at: https://matt.traudt.xyz/static/papers/secdev19-satdomains.pdf

The security properties and threat models between SATA and this document are different. SATA authenticates the connection, we authenticate the downloaded trust information independent of the connection.

SATAs ensures that the TLS connection to a domain is safe against adversaries that can issue TLS certificates for arbitrary domains, but it is not safe against an adversary that can manipulate files on the actual authentic webserver. The proposal ensures the integrity of the published content: https://example.com/.well-known/tor-relay/trust/operator-ids.txt while SATA only ensures that we actually connected to example.com.

SATA solve a much broader problem (issues in PKI), compared to that we have a very narrow problem to solve. Our threat model includes adversaries that can manipulate files on TAs. That threat is not addressed using SATAs. TAs can use semi-trusted distribution mechanisms without giving the distributing webservers the power to trick trust information consumers into accepting manipulated trust information because the file content itself is authenticated.

SATA would also require TAs to generate and manage new keys and run new software, which the current design does not.

kind regards, nusenu

added 1 commit

2271c810 - moved content

Compare with previous version

closed

@nusenu: I am fine closing this MR but thought we could maybe use it to figure out whether there is a good place at TPO to host this kind of proposal. Do you think something like network-health-spec would be useful? Or maybe we should add a proposal section to our wiki pointing to network health proposals?

@nusenu: thanks for comments. My responses below.

SATA authenticates the connection, we authenticate the downloaded trust information independent of the connection.

For purposes of authentication during the connection of course they only authenticate the connection. But SATAs and sattestation do much more than that. This would be like saying that Tor relay IDs are authenticated during circuit establishment while ignoring interactions with dirauths, network properties etc. that they play a role in. As one example, by being incorporated into CT logs they provide an authenticated append-only record of SATAs that can be searched for which SATAs are being claimed for a given domain or given onion address (or in this context, relay ID).

SATAs ensures that the TLS connection to a domain is safe against adversaries that can issue TLS certificates for arbitrary domains, but it is not safe against an adversary that can manipulate files on the actual authentic webserver. The proposal ensures the integrity of the published content: https://example.com/.well-known/tor-relay/trust/operator-ids.txt while SATA only ensures that we actually connected to example.com.

That is just not true. Sattestations can be provided as lists very much as you describe. In fact that was the only option we put out originally in "Self-Authenticating Traditional Domain Names" (IEEE SecDev 02019). But we added the ability to provide them in credentials sent by the sattestee server during a connection for multiple reasons that make sense in application to web authentication.

SATA solve a much broader problem (issues in PKI), compared to that we have a very narrow problem to solve. Our threat model includes adversaries that can manipulate files on TAs. That threat is not addressed using SATAs.

Also not accurate. First of all, if your adversary can hijack (TLS and DNS) connections and manipulate arbitrary content on servers associated with a relay (including offline content), then I don't see how anything can work since the adversary pretty much owns the ability to authenticate anything associated with the identity of the associated relay. If offline content is protected, that is also something SATAs provide. Sattestations are meant to be generated offline and the signed content they authenticate cannot be manipulated by an adversary that otherwise can manipulate content on the server.

(I'm assuming "TA" means 'tradional address', and "files on TAs" means files on webservers for respective TAs. Otherwise my comments above and below won't make sense.)

TAs can use semi-trusted distribution mechanisms without giving the distributing webservers the power to trick trust information consumers into accepting manipulated trust information because the file content itself is authenticated.

Not sure of the point here. Sattestations support arbitrary labels. They can support a standardized labeling introduced for these purposes, that says, for example, "X believes [relay-ID] is to be trusted for all Tor positions". Where [relay-ID] is the (encoding of) the ed25519 identifier for that relay, and X should be a SATA. (It certainly is now, and let's not get distracted here by discussion of alternatives.) Thus if the SATA were for [self-auth-key].wangafu.net then this would give a list of the relays nickm thinks are good. While there can be similar sattestations from SATAs for torproject.org or torsevers.net, etc.

SATA would also require TAs to generate and manage new keys and run new software, which the current design does not.

Well sort of. You expect them to support DNSSEC, which is currently supported on a very small fraction of sites by last studies I checked and (and correctly configured by an even smaller fraction) and has specific disincentive complications.

That said, yes. I am also assuming that TAs have new software. But that is like saying supporting HTTPS required websites to run new software. Services running SATAs have many security, reachability, and performance improvements over those running only status quo mechanisms. And (other than specific new content like sattestations for website or relay trust) this can all be handled by a front end. Unlike setting up a new onionsite for a given TA, the SATA is much less overhead of changes and much more backwards compatible.

I certainly did not mean to imply that one could just grab the SATA designs and/or code, swap "relay ID" for "onion address", and be done. I remain very confident that there is a lot to be leveraged by combining the ideas from the current proposal with those of SATAs.

@syverson I responded to your comment here: https://github.com/nusenu/tor-relay-operator-ids-trust-information/issues/1 I believe that will solve a few misunderstandings :)

@gk there appears to be very limited interest from tpo in this spec so I'll simply keep it on gh for now so I can easily continue working on it without taking up tpo resources.

@gk there appears to be very limited interest from tpo in this spec so I'll simply keep it on gh for now so I can easily continue working on it without taking up tpo resources.

I don't think the interest in your spec is very limited from TPO side. It's an interesting proposal worth thinking about. But, sure, it's up to you if you prefer Github instead of trying to find a place for it (and similar proposals not really belonging to torspec but being Tor relevant) somewhere on our infrastructure. Let us know when/if that sentiment changes on your side at some point.

A Simple Web of Trust for Relay Operator IDs

Merge request reports

Activity