Hi nusenu,
thank you for you feedback.
First I would like to say that this proposal should not be regarded as final but work in progress. Second the changes are behind a feature flag and very unintrusive, so the behvior does not change without explicitly enabling them and they can be easily removed if it turns out that this is not the right direction. Additionally, I think that it is much easier to analyze certain scenarios with a proof of concept in place.
As described in the proposal the idea is to move the DNS name resolution from the exit relays to the client and add DNSSEC validation.
Basic workflow:
* a new connection arrives at the SocksPort * with the socks handshake we learn the target hostname * a new connection for the DNS lookup is created and attached instead of the incoming connection * when the name is resolved the hostname in the original connection is replaced with the IP address * finally the original connection is attached
I can not really say anything about how this design compares to other approaches, since I don't know how I can setup meaningful test scenarios to compare them. However, I would appreciate if you could share how to setup such test environments. For the server part I can provide a DNS server that supports DoT, DoH, and DNSSEC.
Regarding stream isolation, see cypherpunks analysis in the ticket.
Please let me know if you think this approach is worthwhile. Then I will try to answer the remaining questions.
BR Christian
On Mon, 2020-04-27 at 00:56 +0200, nusenu wrote:
Hi Christian,
thanks for your efforts to improve DNS resolution in the tor context.
A few general questions:
- What is the underlying threat model and what threats you are trying
to address in your proposal?
- What use case are you aiming for? Do you propose to make use of
this DNS resolution in Tor Browser by default?
- if so:
- Do you do connection re-use to route multiple DNS queries over a
single connection? (related: RFC 7766)
- How does your proposal (or the user of your proposal - Tor
Browser) ensure stream isolation for DNS queries to avoid profiling based on DNS queries?
- How do you aim to solve the problems of resolver selection and
centralization? if not:
- why not just run existing resolver software (i.e. stubby) over
tor?
- How does your design compare to running existing DNS privacy
protocols over tor that do not require any changes to tor?
- DoT non-opportunistic mode+DNSSEC validation or
- DoH+DNSSEC validation
I would also be interesting to see how your design compares to a design like this (aiming for Tor Browser integration and enabled by default, without tor changes): DoH (RFC 8484) enabled in Tor Browser, the vanilla DoH implementation in Firefox slightly changed so it is stream isolation aware (domains are resolved via the same stream that is used to fetch the HTTP content in all cases where the exit policy allows for that). Resolver selection: pre-configured list in Tor Browser (no implementation or proposal exists at this point)
Filename: 317-secure-dns-name-resolution.txt Title: Improve security aspects of DNS name resolution Author: Christian Hofer Created: 21-Mar-2020 Status: Open
Overview:
This document proposes a solution for handling DNS name resolution within Tor in a secure manner. In order to achieve this the responsibility for name resolution is moved from the exit relays to the clients. Therefore a security aware DNS resolver is required that is able to operate using Tor. DNSResolverNameservers: A list of comma separated nameservers, can be an IPv4, an IPv6, or an onion address. Should allow means to configure the port and supported zones.
How is end-to-end encryption / query confidentiality ensured in the case this configuration parameter contains IPv4/IPv6 addresses?
DNSResolverHiddenServiceZones: A list of comma separatedhidden service zones.
What are "hidden service zones"? what is the impact of listing them in this config parameter and how is it related to RFC 7686?
DNSResolverTrustAnchors: A list of comma separated trustanchors in DS record format. https://www.iana.org/dnssec/files
Does your design support RFC 5011?
DNSResolverMaxCacheEntries: Specifies the maximum number ofcache entries.
Where is the cache located? Is it written to disk? Is the cache stream isolation aware or do you aim to reuse the cache across multiple streams? (which results in correlation issues across streams)
Performance and scalability:
Since there are no direct changes to the protocol and this is an alternative approach for an already existing requirement, there are no performance issues expected. Additionally, the encoding and decoding of DNS message handling as well as the verification takes place on the client side.
A few remarks regarding performance (DNS resolution response time and subsequent content fetches i.e. HTTPS):
- this design increases the network path when the configured resolver
is not the exit relay
- a design that will not use the exit for resolution will likely have
a performance impact on domains that do geoIP based optimizations to allow i.e. HTTP fetches from locations near the exit relay
kind regards, nusenu
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev