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 separated hidden 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 trust anchors in DS > record format. https://www.iana.org/dnssec/files Does your design support RFC 5011? > DNSResolverMaxCacheEntries: Specifies the maximum number of cache > 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 [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
