[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-dev] Support for full DNS resolution and DNSSEC validation
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 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
> 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