Re: [tor-dev] Support for full DNS resolution and DNSSEC validation

[Christian Hofer <chrisss404@xxxxxxxxx>]

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

> 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@xxxxxxxxxxxxxxxxxxxx
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev