On Mon, 2020-05-25 at 21:23 +0200, nusenu wrote:
Christian Hofer:
The thread model is DNS hijacking. Yes, you can prevent DNS hijacking using DoH if you *trust* the resolver you connect to. However, if you want to verify authenticity and integrity of DNS responses you need DNSSEC.
Could you elaborate on the use-case since DNS record authenticity is often just a vehicle to bootstrap some other use-case (for example DANE). What higher level use-case do you have in mind where authenticity of DNS entries provides a value for tor / Tor Browser users?
I am sorry to disappoint you, but I have no higher level use-case in mind. It just felt strange to me that exit relays are able to tamper with DNS records as they please. That is the reason why I started to look into it. On my way I found this old proposal [1] that was never finished and I figured that there seems to be need :-)
However, thinking about it, DNSSEC might be useful for caching DNS records on the client side.
https://gitweb.torproject.org/torspec.git/tree/proposals/219-expanded-dns.tx...
What I'm trying to get to: Authentic IP addresses from A/AAAA records are probably of limited value in the context of a tor client since the exit relay has full control over the routing anyway. If the tor clients asks the exit relay to connect to IP A (which is the actual DNSSEC validated IP address) there is nothing that can stop an exit from routing it to some other IP address.
I understand, then it is not that useful.
That is why I'm trying to get to the bottom of your DNSSEC use-case.
To avoid anonymity set reductions I'm also primarily interested in enabled by default designs (in contrast to opt-in) which brings you to the next problems: performance, scaleability and resolver selection.
Please don't let me discourage you with my questions, they are not meant to. Just trying to understand and hopefully find some common ground to move forward since I see a rather motivated person and it would be a pity to loose that opportunity.
That's fine. I am still willing to contribute.
My vision for DNS privacy in Tor Browser: Be able to visit a HTTPS website without the exit relay learning what domain it was (encrypted DNS + encrypted SNI)
Makes sense. Which nameserver are you planning to use, since the used provider will get all Tor Browser DNS queries? Do you (the Tor project) plan to host your own DNS resolver(s)?
There are a few issues to solve along that path.
In case you are still looking for alternative approaches. When using the implementation from the PR you can hide DNS queries from the exit relay as well.
Things TODO:
* remove all DNSSEC related code in order to reduce complexity * host DNS resolver(s) as hidden service (using HiddenServiceSingleHopMode)
Key differences:
DoH (https connection)
* Better maintainability * Less code * Less complexity
Native (hidden service)
* works for use cases outside of Tor Browser * requires resolvers hosted as hidden services, which might be a performance issue * can use multiple resolvers, not all DNS queries go to a single proivder * ensuring isolation might be easier due to full control over the implementation
kind regards, nusenu
BR Christian
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev