Draft: Sauteed Onions planning - 2023.Q4
This merge request aims to create a concrete roadmap to have Sauteed Onions implemented as a method for Onion Services address translation.
It can be the or part of an "Onion Names" draft plan, addressing the following Tor strategic Key Result for 2023:
Goal 2 (product) - Objective 2 (any person on the planet be able to use Tor to access any online service) - KR 1 - [...] onion names plan draft is concluded.
Closes #16 (closed)
Merge request reports
Activity
added Backlog Onion Services Q4 Research labels
assigned to @rhatto
Implementation stages
There's this idea to implement Sauteed Onions in stages:
- "Weak" being the current implementation with SCT checking.
- "Strong" with a CT log API query behind a load-balanced Onion Service.
- "Extra strong" with the browser having the option do to a prefetch on the existing list of certificates).
- "Full" with non-existence proofs.
Splitting in stages might help the implementation planning for this feature.
Questions:
- Does these stages are meaningful?
- Shall we proceed this way or we have other interesting alternatives?
This topic was first written as a comment in another ticket and was moved to a thread in this merge request so it's easy to track the discussion and the related changes.
-
Tor Specification for Sauteed Onions
A discussion happened during the 2023 Costa Rica meeting in the hotel lobby about whether Sauteed Onions should be a Tor Specification. I still don't have an opinion on this, but some people made strong arguments in favor.
Questions:
- Is that the case?
- If so, how to proceed?
This topic was first written as a comment in another ticket and was moved to a thread in this merge request so it's easy to track the discussion and the related changes.
-
Sauteed Onions and ACME for Onions
It would be interesting to know whether Sauteed Onions could benefit from ACME for Onions, whereas a single X.509 certificate could have SANs for the DNS-name, the Sauteed Onion domain and the .onion address, implementing bi-directional association.
There is already an existing evaluation stating the compatibility between both proposals.
Questions:
- Would be of interest trying to consider bi-directional associations in the certificates between regular domains and .onion domains.
- If so, on which stage it should be implemented?
This topic was first written as a comment in another ticket and was moved to a thread in this merge request so it's easy to track the discussion and the related changes.
-
Non-existence proofs
How/when to handle non-existence proofs?
This topic was first written as a comment in another ticket and was moved to a thread in this merge request so it's easy to track the discussion and the related changes.
-
Subdomains and wildcards
How to handle subdomains or wildcards in SANs?
This topic was first written as a comment in another ticket and was moved to a thread in this merge request so it's easy to track the discussion and the related changes.
-
Sponsorship
Does all (or any) of this work need a sponsor?
This topic was first written as a comment in another ticket and was moved to a thread in this merge request so it's easy to track the discussion and the related changes.
-
Scalability
Questions:
- Which scalability issues should be considered in the roadmap?
- How they can be addressed?
This topic was first written as a comment in another ticket and was moved to a thread in this merge request so it's easy to track the discussion and the related changes.
-
Tor VPN and Sauteed Onions
I would be interesting to know how Sauteed Onions could be implemented in the upcoming "Tor VPN" project, but neither people know how to implement Onion-Location there as well. This may also not be an issue to start road mapping and implementing, but relevant to discuss anyways.
Here are the related placeholder tickets to try to see how Onion Services should be handled by the "Tor VPN":
This topic was first written as a comment in another ticket and was moved to a thread in this merge request so it's easy to track the discussion and the related changes.
-
Size increase in certificates
Roger commented somewhere else that:
(a) the big onion sites like Facebook don't want to get a single cert with both their .com name and their onion name in it, because they don't want to spend those extra 100 bytes times billions of handshakes per day. Maybe they could show the cert just to Tor exit IP addresses, but that is extra complexity too.
This may be a concern preventing some operators to adopt the technology.
If there's no way to fully address this, the proposal could at least discuss this with some estimates on the size increase.
This topic was first written as a comment in another ticket and was moved to a thread in this merge request so it's easy to track the discussion and the related changes.
-
Fallback mechanism
Another comment from Roger to be discussed:
(b) when the site includes its own Onion-Location header, they can easily remove it if the onion site has problems; but if instead Tor Browser users get the mapping from the Certificate Transparency log, what if there is a mapping from two weeks ago that the site doesn't want people to use anymore? It seems we might need some kind of "try the onion but be able to notice if it's not working and fall back to the main site" mechanism in the browser."
This topic was first written as a comment in another ticket and was moved to a thread in this merge request so it's easy to track the discussion and the related changes.
-
Threat analysis
It's important to consider scenarios where this scheme could be abused:
- Rogue certificates having .onion and DNS-based SANs. Such rogue cert could be used to link a regular domain name with an arbitrary .onion address. What would be the impact and mitigations of such attack?
This topic was first written as a comment in another ticket and was moved to a thread in this merge request so it's easy to track the discussion and the related changes.
mentioned in issue #16 (closed)
mentioned in issue tpo/applications/tor-browser#41853
added Roadmap::Future label and removed Backlog label
Sorry for the slow response. First of all, thank you for summarizing the feedback and questions that have been raised. My goal is not to address those now, to instead focus on higher-level comments that hopefully help you navigate.
(Linus has also been part of discussing this response. If anyone would like to chat more in-person, we and Paul will all be at PETS in ~7 days from now.)
To help everyone think about the properties you can possibly get from sauteed onions in its current state (no "but maybe:s..."), this would be my summary:
- Certificate-based onion location: you can redirect sooner (=less latency, and less cells that can be used for traffic analysis), and it would be harder to provide different users different redirects without detection. You have two flavors of the latter, with and without CT enforcement.
- Search API: you can basically query the history of a site's onions as found via HTTPS. So some similar flaws as today's onion location but transparent. We have not explored automatic use of this API in Tor Browser; view it as a secondary source that can be consulted when gaining confidence in onions. This source also stays available even if an HTTPS site gets blocked later; so any sauteed setup you once configured will stay in the public record.
Any additional ideas on how sauteed onions can be used should probably be considered research, including documenting answers to the questions raised.
Here are some concerns, or risks, I see with moving this forward too quickly:
-
Sauteed onions freeload on CAs (the subdomain format we inherited from SATAs). At minimum, I recommend a conversation with Let's Encrypt to communicate what you'd like to do and why. We meant to have such a conversation sometime after publishing the paper, but have been too busy and then it never happened. I'm pointing this out so that the Tor Project won't start recommending something that Let's Encrypt may then ask you not to do, e.g., "please use an X.509 extension instead" or "only associate if there's both a regular domain and an actual .onion address". Having some prototype sites is one thing; fully endorsing/recommending is another.
The preparation for a chat with Let's Encrypt would likely be a torspec proposal, so big +1 for that if you plan to pursue this further.
-
The proposed roadmap is quite heavily focused on CT and associated checks. I worry you will take on more work than initially anticipated, and that too much of that work is "CT stuff" rather than "very useful onion UX stuff".
This is in contrast to just setting up a sauteed site, like forum.torproject.org, which is relatively low overhead and already serves some purpose as there's now a history of any configured onion addresses.
-
I think stage 3 of the proposed roadmap, preloading all sauteed certs, is not going to work. It is one of these things that seemed quite plausible because there are not that many onion associations and "not scaling eventually" would be a good problem to have. But in reality, anyone could make that "not scale tomorrow" by setting up lots and lots of sauteed sites that they never intend to operate after setup. Those sauteed certs would (by design) not go away as they are in CT logs. What we're left with is a very large list, and starting to filter it is non-trivial / not desired.
This is one of the things I was most excited about (because you could do an offline query within Tor Browser before even touching DNS/HTTPS/etc). :<
-
Linus and I will not be able to pitch in anytime soon due to too many other commitments. The best we can offer is continued operation of the current search API at a best-effort level, as well as commenting on torspecs. I am a bit worried our comments may not be timely though, just like this response.
(Sorry for sounding like a bummer, just want to be as upfront as possible so that you can make your plans with as few unknowns as possible.)
All this said, I would of course be excited to see you explore sauteed onions further. It would be fantastic if it achieves your goals with acceptable trade-offs. Trade-offs is certainly a keyword for all onion naming ideas.