On Fri, 2020-05-15 at 15:29 +0000, Alexander Færøy wrote:
Hello Christian,
Hi Alex!
On 2020/04/26 19:37, Christian Hofer wrote:
I have a proposal regarding DNS name resolution.
Ticket: https://trac.torproject.org/projects/tor/ticket/34004 Proposal: https://trac.torproject.org/projects/tor/attachment/ticket/34004/317-secure-... Implementation: https://github.com/torproject/tor/pull/1869
All functioniality is behind the DNSResolver feature flag, so don't forget to activate it before you start testing.
Please let me know what you think.
Thanks for doing this work. I think our DNS subsystem has been lacking behind for a while. This work is exciting.
Generally, after having done one pass over your code, I think the source code is good quality, especially if this is your first contribution to Tor! However, I think this is going to be a bit problematic for us to import.
It will be hard, if not impossible, for Tor's Network Team to adopt 27k LOC's in one pull-request. We will have to have multiple people going over each line repeatedly and try to build up some confidence in this code. If we are to go down this path, with having a complete DNS subsystem in Tor, we need to add some capacity from our side to take this in and maintain it. I think that with the recent layoffs in Tor, it will be hard to achieve in a time-frame that is fair towards you.
There are not many changes to the existing code, but most of the code is new. How could I prepare the changes to simplify the review? Since most parts depend on other parts within this change, I don't think it would be a good approach to split them up in multiple PRs?
One of the goals with our specification process is to have a set of documents, which allows other people to understand how Tor is working to the point where they should be able to implement Tor from scratch if they found that useful. This isn't always possible today, but this is a goal we should have in mind. Your proposal is mostly a specification of the *implementation* of the DNS resolver patches and doesn't contain any information on any changes to the network layer of Tor. Instead, those seem to be referenced as the various DNS related RFCs from the IETF. Configuration options of the Tor binary is largely an implementation detail.
There is only one entry and one exit point, apart from this there are no further changes to the network layer if you consider these changes even as a change to the network layer. See the sections "SocksPort related changes" and "DNSPort related changes" in the proposal. The DNS resolver implementation should of course comply to the DNS RFCs. I would like to try to improve the specification. So, you suggest to remove the section about configuration options and add more details about network layer changes?
I wonder if it would make more sense to have an onion-aware DNSSEC-enabled resolver *outside* of the Tor binary and have a way for Tor to query an external tool for DNS lookups. Such tool should be allowed to use Tor itself for transport of the actual queries. One of the best parts of Tor (in my opinion) is the Pluggable Transport subsystem. This subsystem allows external developers, researchers, and hackers to build new technology that benefits users in censored areas *without* having to alter a single line of C code in tor.git.
Let's say we had a "Pluggable DNS" layer in Tor. Users would be able to configure their Tor process to *never* use the built-in DNS subsystem in Tor, but instead outsource it to an external process that Tor spawns on startup. This process could use .onion's to reach a DNS-over-(TLS|HTTPS|TCP) server as onions themselves aren't looked up via DNS.
Sounds great. Let's start?
A "Pluggable DNS" subsystem would be much less code, I believe, and it wouldn't require us to have a DNS+DNSSEC implementation in the heart of Tor to maintain in the future. Such a system would be similar to the proposed design for Name => Onion lookups defined in proposal #279 by asn, yawning, and dgoulet.
Lastly, I assume it's just for testing purpose, but I don't think we could ship with CloudFlare's DNS-over-Onion services as the default servers for a feature like this without having a discussion in the community about it first :-)
You are right. There is even the DNSResolver flag that defaults to off, which completely disables this feature.
All the best, Alex.
BR Christian