Hi there,
I have a proposal regarding DNS name resolution.
Ticket: https://trac.torproject.org/projects/tor/ticket/34004 Proposal: https://trac.torproject.org/projects/tor/attachment/ticket/34004/317-secure-... Implementation: https://github.com/torproject/tor/pull/1869
All functioniality is behind the DNSResolver feature flag, so don't forget to activate it before you start testing.
Please let me know what you think.
BR Christian
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
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
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.
Do we really need test setups to discuss protocol designs and compare protocols with a common threat model if specs for the protocols are available?
However, I would appreciate if you could share how to setup such test environments.
take your preferred DoT client implementation that supports the strict profile (RFC8310) or your preferred DoH implementation and route it over tor to your resolver of choice.
On Sat, 2020-05-16 at 01:37 +0200, nusenu wrote:
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.
Do we really need test setups to discuss protocol designs and compare protocols with a common threat model if specs for the protocols are available?
I think it depends on the context. However, if you want to neglect the context you can just compare plain DNS employing DNSSEC (authenticity and integrity) to DoH / DoT (confidentiality). There are quite a few comparisons out there, e.g.: [1].
[1] https://blog.circuitsofimagination.com/2018/11/08/dns-o-t-dnssec-dns-o-h.htm...
However, I would appreciate if you could share how to setup such test environments.
take your preferred DoT client implementation that supports the strict profile (RFC8310) or your preferred DoH implementation and route it over tor to your resolver of choice.
If you put it like this, then the proposed design would save the required TLS / HTTPS handshake you have in DoT / DoH and would add authenticity and integrity verification of DNS responses. However, the confidentiality you get with DoH / DoT (at the exit realy, which may not even be necessary?) would be missing.
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On Sun, Apr 26, 2020 at 4:32 PM Christian Hofer chrisss404@gmail.com wrote:
Hi there,
I have a proposal regarding DNS name resolution.
Ticket: https://trac.torproject.org/projects/tor/ticket/34004 Proposal: https://trac.torproject.org/projects/tor/attachment/ticket/34004/317-secure-... Implementation: https://github.com/torproject/tor/pull/1869
All functioniality is behind the DNSResolver feature flag, so don't forget to activate it before you start testing.
Please let me know what you think.
Added to the torspec repository as proposal 317. This is cool stuff! I'm behind in proposal review but I'll try to catch up soon. It's good to see other people with good questions too, here and on the ticket.
peace,
On 26 Apr (19:37:56), Christian Hofer wrote:
Hi there,
Greetings Christian!
I have a proposal regarding DNS name resolution.
Ticket: https://trac.torproject.org/projects/tor/ticket/34004 Proposal: https://trac.torproject.org/projects/tor/attachment/ticket/34004/317-secure-... Implementation: https://github.com/torproject/tor/pull/1869
First, this is quite impressive piece of work. I was _NOT_ expecting a 27k line diff ;).
So the proposal looks very good. I like the idea very much. I honestly thought that you were about to propose a way for Tor to talk to an *external* DNS resolver client application (third part) but I see that client DNSSEC is basically implemented in tor with your patch which is... interesting?
Before we go further, can you walk me through the reasons (if you had thought of it of course) why you didn't use something like libunbound?
There are side effects of adding DNSSEC client support (with our own implementation) that we, people maintaining tor, have to become DNSSEC expert in some ways just to be able to understand what is happening in that code, fix issues but also possibly implement new features if any. That is where a third part library like unbound becomes very nice because they are the experts at providing such features.
Of course, everytime we have to link to an external library we do it carefully and with considerations because of the "yet another attack" vector problem. But adding that much code to support a well known feature like DNSSEC also has huge implications for tor maintainability and security.
Finally, something I noticed and made me itch a bit. You hardcoded a lot of .onions where one appears to be Cloudflare (?) resolver. What are the other addresses? I worry here because default options are always the one used the most so I'm concerned here about shipping hardcoded addresses _within_ our C code.
Thanks! David
On Thu, 2020-05-14 at 15:56 -0400, David Goulet wrote:
On 26 Apr (19:37:56), Christian Hofer wrote:
Hi there,
Greetings Christian!
Hi David!
I have a proposal regarding DNS name resolution.
Ticket: https://trac.torproject.org/projects/tor/ticket/34004 Proposal: https://trac.torproject.org/projects/tor/attachment/ticket/34004/317-secure-... Implementation: https://github.com/torproject/tor/pull/1869
First, this is quite impressive piece of work. I was _NOT_ expecting a 27k line diff ;).
Yeah this might look scary at first, but if you take a closer look it is not that bad.
More than half of the lines account for tests: 15,437
3,584 test_crypto_dnssec.c 1,456 test_crypto_dnssec_openssl.c 726 test_dns_message.c 5,105 test_dns_resolver.c 1,389 test_dns_string.c 3,177 test_dns_wireformat.c
Another big part accounts for containers and translators: 6,531
They don't contain much logic and their main purpose is to translate DNS message <-> wireformat and DNS message <-> string. So this area shouldn't change very often, except you want to add support for new DNS types or the specification for an existing DNS type changes, which shouldn't actually happen.
1,150 dns_message.c 173 dns_message.h 457 dns_message_st.h 199 dns_types.h 1,564 dns_string.c 80 dns_string.h 2,586 dns_wireformat.c 322 dns_wireformat.h
The most interesting part accounts (only) for 4,970 lines (2,066 relevant lines). It contains all the DNS resolution and DNSSEC validation logic.
* The dns_lookup_st contains state related types that lives in AP connections (entry_connection_t). * The dns_resolver is responsible for sending and receiving DNS messages, validating DNS messages using crypto_dnssec, and caching DNS messages. * The crypto_dnssec contains all required DNSSEC algorithms.
lines / relevant / coverage / filename
57 / 0 / 100.0 / dns_lookup_st.h 2,564 / 1,197 / 98.75 / dns_resolver.c 179 / 0 / 100.0 / dns_resolver.h 1,478 / 684 / 98.83 / crypto_dnssec.c 495 / 185 / 99.46 / crypto_dnssec_openssl.c 197 / 0 / 100.0 / crypto_dnssec.h
These numbers were taken from the coveralls report: https://coveralls.io/builds/30352518
So the proposal looks very good. I like the idea very much. I honestly thought that you were about to propose a way for Tor to talk to an *external* DNS resolver client application (third part) but I see that client DNSSEC is basically implemented in tor with your patch which is... interesting?
Before we go further, can you walk me through the reasons (if you had thought of it of course) why you didn't use something like libunbound?
I might be wrong, please correct me if so. The scenario I was aiming for is when the target address that is received within the socks handshake in connection_ap_handshake_process_socks is a hostname. As far as I understand it, in this case the name resolution is done at the exit relay that is also responsible for retrieving the contents from the target. This means that the user has to trust the exit relay in terms of name resolution? However, I am not sure if this is a valid use case or if you can cover this using libunbound. So please let me know.
Using the DNS resolver would resolve the hostname upfront in a separate connection that is not related to the connection that is responsible for retrieving the contents from the target. Additionally, the user has control over the nameserver that should be used for name resolution and is also able to verify the response using DNSSEC. So this should reduces the number of entities that must be trusted.
There are side effects of adding DNSSEC client support (with our own implementation) that we, people maintaining tor, have to become DNSSEC expert in some ways just to be able to understand what is happening in that code, fix issues but also possibly implement new features if any. That is where a third part library like unbound becomes very nice because they are the experts at providing such features.
I can understand this.
Of course, everytime we have to link to an external library we do it carefully and with considerations because of the "yet another attack" vector problem. But adding that much code to support a well known feature like DNSSEC also has huge implications for tor maintainability and security.
Finally, something I noticed and made me itch a bit. You hardcoded a lot of .onions where one appears to be Cloudflare (?) resolver. What are the other addresses? I worry here because default options are always the one used the most so I'm concerned here about shipping hardcoded addresses _within_ our C code.
Regarding the the default configuration. There is a configuration called DNSResolver which defaults to off. As long as this flag is turned off nothing changes related to DNS resolution. Yes, the first onion is the Cloudflare resolver. The other onion addresses are DNS resolvers (PowerDNS Recursor) behind hidden services which I used and am still using for testing. They can be easily changed / removed (?) since it is only a configuration and as mentioned if you want to activate this feature you have to enable the DNSResolver flag first.
Final remarks. When I started, I didn't expect it to get this big, and frankly, if I had known before, I might not have even started. However, I learned a lot about DNS, DNSSEC, SOCKS, and Tor. So even if you decide not to merge it, it was not a waste :-)
In the end you have to decide if you want to add this and I can understand if you don't want to maintain DNS related code. At least it would be interesting how the different solutions compare regarding performance, security, and maintainability. What do you think?
Thanks! David
BR Christian
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On Fri, May 15, 2020 at 05:39:23PM +0200, Christian Hofer wrote:
Final remarks. When I started, I didn't expect it to get this big, and frankly, if I had known before, I might not have even started. However, I learned a lot about DNS, DNSSEC, SOCKS, and Tor. So even if you decide not to merge it, it was not a waste :-)
Hi Christian!
Given the above learning, let me ask you a related question. Or maybe rather, a question about an alternative design.
As I understand it, the design in your patch is basically to let the Tor client talk via Tor to an authenticated dns server that the client chooses, and do the DNS interaction to satisfy itself that the DNS answer is correct.
And because the DNS server is a different destination than the original stream destination, this requires another round-trip through Tor, for doing the resolve?
And maybe it's way worse than that, because to do DNSSEC properly, you need to go up the chain, with a new round-trip over Tor for each link in the chain?
Whereas in the current Tor design, we have no extra round-trips for the DNS component, because the client sends the hostname in the BEGIN cell, and the exit relay resolves it and connects, and then sends the IP address back in the CONNECTED cell in case the client wanted to know it.
To me, extra round-trips over the Tor network in the critical path of "user clicks and waits for the website to load" are really bad, and need a really good argument for being there. Given that DNS is only one piece of the connection -- after all, the exit relay can still route you somewhere else -- it's hard to see how this case brings enough benefit to justify the extra round trip(s).
Ok, with that as a preface, here is an alternative design: the Tor client sends the hostname to the exit relay, along with a request for dnssec proofs. The exit relay uses its own dnssec server to convince itself that its answer is right. Then it returns the IP address in the CONNECTED cell as it does now, and also it returns a set of dnssec answers that the client can use to reconstruct the dnssec interaction and convince itself of the result too.
This design adds no extra round trips (yay), but it requires a notion of "dnssec chain stapling" that I think doesn't entirely exist yet. Alex points me to a long-expired IETF draft from agl on the topic: https://tools.ietf.org/html/draft-agl-dane-serializechain-01 and I don't know if there is newer progress.
I would also worry about the overall size of the stapled answers -- if we add another 50KBytes to every stream interaction in Tor, that's probably not worth it. Whereas adding another 1KByte could be a great tradeoff.
Yet another twist here is that it's hard for the client to cache answers, or to cache intermediate certs in the chain, because changing behavior based on cached answers can reveal the client's past browsing history.
Do these goals make sense? :)
Thanks! --Roger
To me, extra round-trips over the Tor network in the critical path of "user clicks and waits for the website to load" are really bad, and need a really good argument for being there. Given that DNS is only one piece of the connection -- after all, the exit relay can still route you somewhere else -- it's hard to see how this case brings enough benefit to justify the extra round trip(s).
Ok, with that as a preface, here is an alternative design: the Tor client sends the hostname to the exit relay, along with a request for dnssec proofs. The exit relay uses its own dnssec server to convince itself that its answer is right. Then it returns the IP address in the CONNECTED cell as it does now, and also it returns a set of dnssec answers that the client can use to reconstruct the dnssec interaction and convince itself of the result too.
This design adds no extra round trips (yay), but it requires a notion of "dnssec chain stapling" that I think doesn't entirely exist yet. Alex points me to a long-expired IETF draft from agl on the topic: https://tools.ietf.org/html/draft-agl-dane-serializechain-01 and I don't know if there is newer progress.
also expired but newer https://datatracker.ietf.org/doc/draft-ietf-tls-dnssec-chain-extension/
I would also worry about the overall size of the stapled answers -- if we add another 50KBytes to every stream interaction in Tor, that's probably not worth it. Whereas adding another 1KByte could be a great tradeoff.
Yet another twist here is that it's hard for the client to cache answers, or to cache intermediate certs in the chain, because changing behavior based on cached answers can reveal the client's past browsing history.
I share your concerns on performance (additional round trips) and caching and I find it also important to note that in the context of tor browser (probably the main use case of tor) encrypted DNS (confidentiality) is more relevant than DNSSEC (integrity), especially as soon as ESNI becomes reality. https://datatracker.ietf.org/doc/draft-ietf-tls-esni/ That will allow for using tor exits without disclosing the visited domain to the exit relay and no more issues with exits with broken DNS. DNSSEC would still be valuable for TLS verification but DANE for https does not appear to be a thing.
On Fri, 2020-05-15 at 14:30 -0400, Roger Dingledine wrote:
On Fri, May 15, 2020 at 05:39:23PM +0200, Christian Hofer wrote:
Final remarks. When I started, I didn't expect it to get this big, and frankly, if I had known before, I might not have even started. However, I learned a lot about DNS, DNSSEC, SOCKS, and Tor. So even if you decide not to merge it, it was not a waste :-)
Hi Christian!
Hi Roger!
Given the above learning, let me ask you a related question. Or maybe rather, a question about an alternative design.
As I understand it, the design in your patch is basically to let the Tor client talk via Tor to an authenticated dns server that the client chooses, and do the DNS interaction to satisfy itself that the DNS answer is correct.
Yes. Exactly.
And because the DNS server is a different destination than the original stream destination, this requires another round-trip through Tor, for doing the resolve?
And maybe it's way worse than that, because to do DNSSEC properly, you need to go up the chain, with a new round-trip over Tor for each link in the chain?
Yes, that is a big concern. However, that is the trade-off you have to consider (performance vs security).
Whereas in the current Tor design, we have no extra round-trips for the DNS component, because the client sends the hostname in the BEGIN cell, and the exit relay resolves it and connects, and then sends the IP address back in the CONNECTED cell in case the client wanted to know it.
To me, extra round-trips over the Tor network in the critical path of "user clicks and waits for the website to load" are really bad, and need a really good argument for being there. Given that DNS is only one piece of the connection -- after all, the exit relay can still route you somewhere else -- it's hard to see how this case brings enough benefit to justify the extra round trip(s).
I understand.
Ok, with that as a preface, here is an alternative design: the Tor client sends the hostname to the exit relay, along with a request for dnssec proofs. The exit relay uses its own dnssec server to convince itself that its answer is right. Then it returns the IP address in the CONNECTED cell as it does now, and also it returns a set of dnssec answers that the client can use to reconstruct the dnssec interaction and convince itself of the result too.
This design adds no extra round trips (yay), but it requires a notion of "dnssec chain stapling" that I think doesn't entirely exist yet. Alex points me to a long-expired IETF draft from agl on the topic: https://tools.ietf.org/html/draft-agl-dane-serializechain-01 and I don't know if there is newer progress.
Sounds very interesting. This would definitely save a lot of time (round trips).
I would also worry about the overall size of the stapled answers -- if we add another 50KBytes to every stream interaction in Tor, that's probably not worth it. Whereas adding another 1KByte could be a great tradeoff.
Yet another twist here is that it's hard for the client to cache answers, or to cache intermediate certs in the chain, because changing behavior based on cached answers can reveal the client's past browsing history.
For my proposal this is true. For your proposal if you get all DNS messages required for performing chain validation in one big batch you don't have to cache intermediates but only the resulting DNS record and caching would be feasible.
Do these goals make sense? :)
Yes, I think this would be a big improvement. Let me know if you plan to start working on a design / implementation to get this done.
Thanks! --Roger
BR Christian
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On Fri, 2020-05-15 at 14:30 -0400, Roger Dingledine wrote:
On Fri, May 15, 2020 at 05:39:23PM +0200, Christian Hofer wrote:
Final remarks. When I started, I didn't expect it to get this big, and frankly, if I had known before, I might not have even started. However, I learned a lot about DNS, DNSSEC, SOCKS, and Tor. So even if you decide not to merge it, it was not a waste :-)
Hi Christian!
Given the above learning, let me ask you a related question. Or maybe rather, a question about an alternative design.
As I understand it, the design in your patch is basically to let the Tor client talk via Tor to an authenticated dns server that the client chooses, and do the DNS interaction to satisfy itself that the DNS answer is correct.
And because the DNS server is a different destination than the original stream destination, this requires another round-trip through Tor, for doing the resolve?
And maybe it's way worse than that, because to do DNSSEC properly, you need to go up the chain, with a new round-trip over Tor for each link in the chain?
Whereas in the current Tor design, we have no extra round-trips for the DNS component, because the client sends the hostname in the BEGIN cell, and the exit relay resolves it and connects, and then sends the IP address back in the CONNECTED cell in case the client wanted to know it.
To me, extra round-trips over the Tor network in the critical path of "user clicks and waits for the website to load" are really bad, and need a really good argument for being there. Given that DNS is only one piece of the connection -- after all, the exit relay can still route you somewhere else -- it's hard to see how this case brings enough benefit to justify the extra round trip(s).
Ok, with that as a preface, here is an alternative design: the Tor client sends the hostname to the exit relay, along with a request for dnssec proofs. The exit relay uses its own dnssec server to convince itself that its answer is right. Then it returns the IP address in the CONNECTED cell as it does now, and also it returns a set of dnssec answers that the client can use to reconstruct the dnssec interaction and convince itself of the result too.
This design adds no extra round trips (yay), but it requires a notion of "dnssec chain stapling" that I think doesn't entirely exist yet. Alex points me to a long-expired IETF draft from agl on the topic: https://tools.ietf.org/html/draft-agl-dane-serializechain-01 and I don't know if there is newer progress.
I would also worry about the overall size of the stapled answers -- if we add another 50KBytes to every stream interaction in Tor, that's probably not worth it. Whereas adding another 1KByte could be a great tradeoff.
A follow-up to answer sizes. Here is a list of domain lookups with sizes in wireformat (A record including the chain up to the root zone). See attachments for more details on the contents.
aus5.mozilla.org / 12 RRs / 8968 bytes / 8.8 KB / signed / 2 CNAMEs / 3 TLDs example.com / 6 RRs / 4241 bytes / 4.1 KB / signed / 0 CNAMEs / 1 TLD www.dnssec-ok.acei.ca / 11 RRs / 8405 bytes / 8.2 KB / signed / 1 CNAME / 2 TLDs www.dnssec-invalid.acei.ca / 11 RRs / 8495 bytes / 8.3 KB / signed / 1 CNAME / 2 TLDs www.torproject.org / 6 RRs / 4401 bytes / 4.3 KB / signed / 0 CNAMEs / 1 TLD duckduckgo.com / 5 RRs / 3053 bytes / 3.0 KB / unsigned / 0 CNAMEs / 1 TLD cdnjs.cloudflare.com / 6 RRs / 2955 bytes / 2.9 KB / signed / 0 CNAMEs / 1 TLD matt.traudt.xyz / 14 RRs / 9011 bytes / 8.8 KB / signed / 2 CNAMEs / 3 TLDs www.norid.no / 6 RRs / 4042 bytes / 3.9 KB / signed / 1 CNAME / 1 TLD www.wikipedia.org / 6 RRs / 4212 bytes / 4.1 KB / unsigned / 1 CNAME / 1 TLD enabled.dnssec.hkirc.hk / 10 RRs / 7542 bytes / 7.4 KB / signed / 0 CNAMEs / 1 TLD
Yet another twist here is that it's hard for the client to cache answers, or to cache intermediate certs in the chain, because changing behavior based on cached answers can reveal the client's past browsing history.
Do these goals make sense? :)
Thanks! --Roger
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Before we go further, can you walk me through the reasons (if you had thought of it of course) why you didn't use something like libunbound?
There are side effects of adding DNSSEC client support (with our own implementation) that we, people maintaining tor, have to become DNSSEC expert in some ways just to be able to understand what is happening in that code, fix issues but also possibly implement new features if any. That is where a third part library like unbound becomes very nice because they are the experts at providing such features.
Of course, everytime we have to link to an external library we do it carefully and with considerations because of the "yet another attack" vector problem. But adding that much code to support a well known feature like DNSSEC also has huge implications for tor maintainability and security.
Finally, something I noticed and made me itch a bit. You hardcoded a lot of .onions where one appears to be Cloudflare (?) resolver. What are the other addresses? I worry here because default options are always the one used the most so I'm concerned here about shipping hardcoded addresses _within_ our C code.
+1 for "don't roll your own DNS(SEC) implementation". There are people that do DNS(SEC) for years, should the torproject really implement and maintain its own custom DNS stub resolver and DNSSEC validator?
Also consider that DNS is moving towards DNS encryption protocols (DoT and DoH) and firefox has DoH support that could be made stream isolation aware. Using open protocols will increase the availability of multiple public resolvers speaking that protocol.
On Sat, 2020-05-16 at 01:37 +0200, nusenu wrote:
Before we go further, can you walk me through the reasons (if you had thought of it of course) why you didn't use something like libunbound?
There are side effects of adding DNSSEC client support (with our own implementation) that we, people maintaining tor, have to become DNSSEC expert in some ways just to be able to understand what is happening in that code, fix issues but also possibly implement new features if any. That is where a third part library like unbound becomes very nice because they are the experts at providing such features.
Of course, everytime we have to link to an external library we do it carefully and with considerations because of the "yet another attack" vector problem. But adding that much code to support a well known feature like DNSSEC also has huge implications for tor maintainability and security.
Finally, something I noticed and made me itch a bit. You hardcoded a lot of .onions where one appears to be Cloudflare (?) resolver. What are the other addresses? I worry here because default options are always the one used the most so I'm concerned here about shipping hardcoded addresses _within_ our C code.
+1 for "don't roll your own DNS(SEC) implementation". There are people that do DNS(SEC) for years, should the torproject really implement and maintain its own custom DNS stub resolver and DNSSEC validator?
Yep. I agree in general. I think this is a hard decision someone has to take.
Also consider that DNS is moving towards DNS encryption protocols (DoT and DoH) and firefox has DoH support that could be made stream isolation aware. Using open protocols will increase the availability of multiple public resolvers speaking that protocol.
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Hello Christian,
On 2020/04/26 19:37, Christian Hofer wrote:
I have a proposal regarding DNS name resolution.
Ticket: https://trac.torproject.org/projects/tor/ticket/34004 Proposal: https://trac.torproject.org/projects/tor/attachment/ticket/34004/317-secure-... Implementation: https://github.com/torproject/tor/pull/1869
All functioniality is behind the DNSResolver feature flag, so don't forget to activate it before you start testing.
Please let me know what you think.
Thanks for doing this work. I think our DNS subsystem has been lacking behind for a while. This work is exciting.
Generally, after having done one pass over your code, I think the source code is good quality, especially if this is your first contribution to Tor! However, I think this is going to be a bit problematic for us to import.
It will be hard, if not impossible, for Tor's Network Team to adopt 27k LOC's in one pull-request. We will have to have multiple people going over each line repeatedly and try to build up some confidence in this code. If we are to go down this path, with having a complete DNS subsystem in Tor, we need to add some capacity from our side to take this in and maintain it. I think that with the recent layoffs in Tor, it will be hard to achieve in a time-frame that is fair towards you.
One of the goals with our specification process is to have a set of documents, which allows other people to understand how Tor is working to the point where they should be able to implement Tor from scratch if they found that useful. This isn't always possible today, but this is a goal we should have in mind. Your proposal is mostly a specification of the *implementation* of the DNS resolver patches and doesn't contain any information on any changes to the network layer of Tor. Instead, those seem to be referenced as the various DNS related RFCs from the IETF. Configuration options of the Tor binary is largely an implementation detail.
I wonder if it would make more sense to have an onion-aware DNSSEC-enabled resolver *outside* of the Tor binary and have a way for Tor to query an external tool for DNS lookups. Such tool should be allowed to use Tor itself for transport of the actual queries. One of the best parts of Tor (in my opinion) is the Pluggable Transport subsystem. This subsystem allows external developers, researchers, and hackers to build new technology that benefits users in censored areas *without* having to alter a single line of C code in tor.git.
Let's say we had a "Pluggable DNS" layer in Tor. Users would be able to configure their Tor process to *never* use the built-in DNS subsystem in Tor, but instead outsource it to an external process that Tor spawns on startup. This process could use .onion's to reach a DNS-over-(TLS|HTTPS|TCP) server as onions themselves aren't looked up via DNS.
A "Pluggable DNS" subsystem would be much less code, I believe, and it wouldn't require us to have a DNS+DNSSEC implementation in the heart of Tor to maintain in the future. Such a system would be similar to the proposed design for Name => Onion lookups defined in proposal #279 by asn, yawning, and dgoulet.
Lastly, I assume it's just for testing purpose, but I don't think we could ship with CloudFlare's DNS-over-Onion services as the default servers for a feature like this without having a discussion in the community about it first :-)
All the best, Alex.
Alexander Færøy:
I wonder if it would make more sense to have an onion-aware DNSSEC-enabled resolver *outside* of the Tor binary and have a way for Tor to query an external tool for DNS lookups. Such tool should be allowed to use Tor itself for transport of the actual queries. One of the best parts of Tor (in my opinion) is the Pluggable Transport subsystem. This subsystem allows external developers, researchers, and hackers to build new technology that benefits users in censored areas *without* having to alter a single line of C code in tor.git.
Let's say we had a "Pluggable DNS" layer in Tor. Users would be able to configure their Tor process to *never* use the built-in DNS subsystem in Tor, but instead outsource it to an external process that Tor spawns on startup. This process could use .onion's to reach a DNS-over-(TLS|HTTPS|TCP) server as onions themselves aren't looked up via DNS.
A "Pluggable DNS" subsystem would be much less code, I believe, and it wouldn't require us to have a DNS+DNSSEC implementation in the heart of Tor to maintain in the future. Such a system would be similar to the proposed design for Name => Onion lookups defined in proposal #279 by asn, yawning, and dgoulet.
Hi Alex,
FYI I already wrote a Prop279 provider that looks up the names via DNS (it's aptly named "dns-prop279"); it does pretty much exactly what you describe. It doesn't handle DNSSEC validation itself (it assumes that you've specified a DNS server that you trust -- most likely one running on localhost). Stream isolation can be handled via an EDNS0 field (and I'm guessing it would not be difficult to patch an existing DNS server to respect that EDNS0 field). I wouldn't be surprised if it's easy to make dns-prop279 do DNSSEC validation itself (and not use a localhost-based DNS server) if that's desired -- the library it uses (miekg/dns) does claim to support DNSSEC validation, though I've never tried testing that feature.
I originally wrote dns-prop279 for Namecoin purposes, but I see no reason it couldn't be used to achieve DNSSEC support in Tor. If there's interest in pursuing this, let me know, I'm happy to contribute.
Code is at https://github.com/namecoin/dns-prop279
Cheers,
Hey Jeremy,
On 2020/05/15 15:53, Jeremy Rand wrote:
FYI I already wrote a Prop279 provider that looks up the names via DNS (it's aptly named "dns-prop279"); it does pretty much exactly what you describe. It doesn't handle DNSSEC validation itself (it assumes that you've specified a DNS server that you trust -- most likely one running on localhost). Stream isolation can be handled via an EDNS0 field (and I'm guessing it would not be difficult to patch an existing DNS server to respect that EDNS0 field). I wouldn't be surprised if it's easy to make dns-prop279 do DNSSEC validation itself (and not use a localhost-based DNS server) if that's desired -- the library it uses (miekg/dns) does claim to support DNSSEC validation, though I've never tried testing that feature.
Very interesting.
I think proposal #279 only tries to solve the subset of name look ups, which is about looking up onions from a human name. The work in this thread is to replace all name lookups *except* for Onions. It could very well be that it would be easier to extend proposal #279 by having it handle all lookups and not just for .onion's, but I think my intuition says that it should be two different systems as onion lookups is still a much more open question whereas Tor will need to support ordinary DNS for many years into the future.
If `OnionNamePlugin` allowed you to specify `.*` for "everything" as the TLD specifier, then it might be possible to implement such system using proposal #279 :-)
All the best, Alex.
Alexander Færøy:
Hey Jeremy,
On 2020/05/15 15:53, Jeremy Rand wrote:
FYI I already wrote a Prop279 provider that looks up the names via DNS (it's aptly named "dns-prop279"); it does pretty much exactly what you describe. It doesn't handle DNSSEC validation itself (it assumes that you've specified a DNS server that you trust -- most likely one running on localhost). Stream isolation can be handled via an EDNS0 field (and I'm guessing it would not be difficult to patch an existing DNS server to respect that EDNS0 field). I wouldn't be surprised if it's easy to make dns-prop279 do DNSSEC validation itself (and not use a localhost-based DNS server) if that's desired -- the library it uses (miekg/dns) does claim to support DNSSEC validation, though I've never tried testing that feature.
Very interesting.
I think proposal #279 only tries to solve the subset of name look ups, which is about looking up onions from a human name. The work in this thread is to replace all name lookups *except* for Onions. It could very well be that it would be easier to extend proposal #279 by having it handle all lookups and not just for .onion's, but I think my intuition says that it should be two different systems as onion lookups is still a much more open question whereas Tor will need to support ordinary DNS for many years into the future.
If `OnionNamePlugin` allowed you to specify `.*` for "everything" as the TLD specifier, then it might be possible to implement such system using proposal #279 :-)
Hi Alex,
The Prop279 spec text is ambiguous about whether the target is required to be a .onion domain, but the implementations (TorNS and StemNS) do not have that restriction. TorNS and StemNS allow a Prop279 plugin to advertise acceptance of any domain suffix (haven't explicitly tried the root zone as an suffix, but if that doesn't work, it's a bug that should be easy to fix) and can resolve them to any result (e.g. an IP address, a .onion domain, or another DNS name a la CNAME).
Cheers,
Hey,
On 2020/05/15 16:36, Jeremy Rand wrote:
The Prop279 spec text is ambiguous about whether the target is required to be a .onion domain, but the implementations (TorNS and StemNS) do not have that restriction. TorNS and StemNS allow a Prop279 plugin to advertise acceptance of any domain suffix (haven't explicitly tried the root zone as an suffix, but if that doesn't work, it's a bug that should be easy to fix) and can resolve them to any result (e.g. an IP address, a .onion domain, or another DNS name a la CNAME).
In proposal #279 the subprocess passes the `RESOLVED` message to Tor once it is has completed a name look up. The `RESOLVED` message is defined as follows:
``When the name plugin completes the name resolution, it prints the following line in its stdout:
RESOLVED <QUERY_ID> <STATUS_CODE> <RESULT>
where QUERY_ID is the corresponding query ID and STATUS_CODE is an integer status code. RESULT is the resolution result (an onion address) or an error message if the resolution was not succesful.''
Here the `<RESULT>` must be an onion address. We would have to change that, such that an IP address can be returned as well :-)
All the best, Alex.
Alexander Færøy:
Hey,
On 2020/05/15 16:36, Jeremy Rand wrote:
The Prop279 spec text is ambiguous about whether the target is required to be a .onion domain, but the implementations (TorNS and StemNS) do not have that restriction. TorNS and StemNS allow a Prop279 plugin to advertise acceptance of any domain suffix (haven't explicitly tried the root zone as an suffix, but if that doesn't work, it's a bug that should be easy to fix) and can resolve them to any result (e.g. an IP address, a .onion domain, or another DNS name a la CNAME).
In proposal #279 the subprocess passes the `RESOLVED` message to Tor once it is has completed a name look up. The `RESOLVED` message is defined as follows:
``When the name plugin completes the name resolution, it prints the following line in its stdout: RESOLVED <QUERY_ID> <STATUS_CODE> <RESULT> where QUERY_ID is the corresponding query ID and STATUS_CODE is an integer status code. RESULT is the resolution result (an onion address) or an error message if the resolution was not succesful.''Here the `<RESULT>` must be an onion address. We would have to change that, such that an IP address can be returned as well :-)
Hi Alex,
The ambiguity I was referring to is that while the section you quote does require that the result be a .onion domain, below it is this note:
Tor MUST validate that the resolution result is a valid .onion name. XXX should we also accept IPs and regular domain results???
Prop279 is clearly labeled as a draft, so this makes it appear that no decision was reached on whether the result should be required to be a .onion domain.
My opinion is that accepting non-.onion addresses as results is desirable (both because it's useful for the Namecoin use case and because it's useful for the DNSSEC use case that we're discussing).
Cheers,
On Fri, 2020-05-15 at 15:29 +0000, Alexander Færøy wrote:
Hello Christian,
Hi Alex!
On 2020/04/26 19:37, Christian Hofer wrote:
I have a proposal regarding DNS name resolution.
Ticket: https://trac.torproject.org/projects/tor/ticket/34004 Proposal: https://trac.torproject.org/projects/tor/attachment/ticket/34004/317-secure-... Implementation: https://github.com/torproject/tor/pull/1869
All functioniality is behind the DNSResolver feature flag, so don't forget to activate it before you start testing.
Please let me know what you think.
Thanks for doing this work. I think our DNS subsystem has been lacking behind for a while. This work is exciting.
Generally, after having done one pass over your code, I think the source code is good quality, especially if this is your first contribution to Tor! However, I think this is going to be a bit problematic for us to import.
It will be hard, if not impossible, for Tor's Network Team to adopt 27k LOC's in one pull-request. We will have to have multiple people going over each line repeatedly and try to build up some confidence in this code. If we are to go down this path, with having a complete DNS subsystem in Tor, we need to add some capacity from our side to take this in and maintain it. I think that with the recent layoffs in Tor, it will be hard to achieve in a time-frame that is fair towards you.
There are not many changes to the existing code, but most of the code is new. How could I prepare the changes to simplify the review? Since most parts depend on other parts within this change, I don't think it would be a good approach to split them up in multiple PRs?
One of the goals with our specification process is to have a set of documents, which allows other people to understand how Tor is working to the point where they should be able to implement Tor from scratch if they found that useful. This isn't always possible today, but this is a goal we should have in mind. Your proposal is mostly a specification of the *implementation* of the DNS resolver patches and doesn't contain any information on any changes to the network layer of Tor. Instead, those seem to be referenced as the various DNS related RFCs from the IETF. Configuration options of the Tor binary is largely an implementation detail.
There is only one entry and one exit point, apart from this there are no further changes to the network layer if you consider these changes even as a change to the network layer. See the sections "SocksPort related changes" and "DNSPort related changes" in the proposal. The DNS resolver implementation should of course comply to the DNS RFCs. I would like to try to improve the specification. So, you suggest to remove the section about configuration options and add more details about network layer changes?
I wonder if it would make more sense to have an onion-aware DNSSEC-enabled resolver *outside* of the Tor binary and have a way for Tor to query an external tool for DNS lookups. Such tool should be allowed to use Tor itself for transport of the actual queries. One of the best parts of Tor (in my opinion) is the Pluggable Transport subsystem. This subsystem allows external developers, researchers, and hackers to build new technology that benefits users in censored areas *without* having to alter a single line of C code in tor.git.
Let's say we had a "Pluggable DNS" layer in Tor. Users would be able to configure their Tor process to *never* use the built-in DNS subsystem in Tor, but instead outsource it to an external process that Tor spawns on startup. This process could use .onion's to reach a DNS-over-(TLS|HTTPS|TCP) server as onions themselves aren't looked up via DNS.
Sounds great. Let's start?
A "Pluggable DNS" subsystem would be much less code, I believe, and it wouldn't require us to have a DNS+DNSSEC implementation in the heart of Tor to maintain in the future. Such a system would be similar to the proposed design for Name => Onion lookups defined in proposal #279 by asn, yawning, and dgoulet.
Lastly, I assume it's just for testing purpose, but I don't think we could ship with CloudFlare's DNS-over-Onion services as the default servers for a feature like this without having a discussion in the community about it first :-)
You are right. There is even the DNSResolver flag that defaults to off, which completely disables this feature.
All the best, Alex.
BR Christian
Alexander Færøy:
I wonder if it would make more sense to have an onion-aware DNSSEC-enabled resolver *outside* of the Tor binary and have a way for Tor to query an external tool for DNS lookups.
I'm also in favor of this approach, and you can do this today with no code changes to tor at all.
CF demonstrated it even before DoH/RFC8484 was finalized: https://blog.cloudflare.com/welcome-hidden-resolver/
Such tool should be allowed to use Tor itself for transport of the actual queries. One of the best parts of Tor (in my opinion) is the Pluggable Transport subsystem. This subsystem allows external developers, researchers, and hackers to build new technology that benefits users in censored areas *without* having to alter a single line of C code in tor.git.
Let's say we had a "Pluggable DNS" layer in Tor. Users would be able to configure their Tor process to *never* use the built-in DNS subsystem in Tor, but instead outsource it to an external process that Tor spawns on startup. This process could use .onion's to reach a DNS-over-(TLS|HTTPS|TCP) server as onions themselves aren't looked up via DNS.
+ 1 for DoT and DoH over tor, especially due to the DoH implementation that is available in firefox (it would still require work on stream isolation and caching risks to ensure the usual first party isolation). In terms of achieving a big improvement on tor browser users in the context of DNS this would be the most effective path to spend coding resources on in my opinion.
On Sat, 2020-05-16 at 01:37 +0200, nusenu wrote:
Alexander Færøy:
I wonder if it would make more sense to have an onion-aware DNSSEC-enabled resolver *outside* of the Tor binary and have a way for Tor to query an external tool for DNS lookups.
I'm also in favor of this approach, and you can do this today with no code changes to tor at all.
CF demonstrated it even before DoH/RFC8484 was finalized: https://blog.cloudflare.com/welcome-hidden-resolver/
Do you have DNSSEC validation in this approach? Looking at [1] it seems that it is only a proxy forwarding requests. I can not see any verification of answers. What you achieve here is that you no longer have to trust the exit relays, but now you have to trust CF. I don't think this such a big improvement.
If you want to add DNSSEC validation to this setup using unbound or something else you have the issue with additional round-trips as pointed out by Roger. And you have no means to reduce them in this scenario.
[1] https://github.com/cloudflare/cloudflared
Such tool should be allowed to use Tor itself for transport of the actual queries. One of the best parts of Tor (in my opinion) is the Pluggable Transport subsystem. This subsystem allows external developers, researchers, and hackers to build new technology that benefits users in censored areas *without* having to alter a single line of C code in tor.git.
Let's say we had a "Pluggable DNS" layer in Tor. Users would be able to configure their Tor process to *never* use the built-in DNS subsystem in Tor, but instead outsource it to an external process that Tor spawns on startup. This process could use .onion's to reach a DNS-over-(TLS|HTTPS|TCP) server as onions themselves aren't looked up via DNS.
- 1 for DoT and DoH over tor, especially due to the DoH
implementation that is available in firefox (it would still require work on stream isolation and caching risks to ensure the usual first party isolation). In terms of achieving a big improvement on tor browser users in the context of DNS this would be the most effective path to spend coding resources on in my opinion.
It seems that Firefox's DoH implementation does not employ DNSSEC validation, see [2]. They trust CF doing it for them. Be careful here.
Furthermore, there are privacy concerns about additional metadata regarding the use of DoH (agent headers, language settings, and cookies) see [3]. To be fair I have to admit that I have not looked into this myself.
[2] https://support.mozilla.org/en-US/kb/dns-over-https-doh-faqs#w_do-you-valida... [3] https://nlnog.net/static/nlnogday2019/5_NLNOG_day_2019_Bert_Hubert_DNS_TLS_P...
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Christian Hofer:
On Sat, 2020-05-16 at 01:37 +0200, nusenu wrote:
Alexander Færøy:
I wonder if it would make more sense to have an onion-aware DNSSEC-enabled resolver *outside* of the Tor binary and have a way for Tor to query an external tool for DNS lookups.
I'm also in favor of this approach, and you can do this today with no code changes to tor at all.
CF demonstrated it even before DoH/RFC8484 was finalized: https://blog.cloudflare.com/welcome-hidden-resolver/
Do you have DNSSEC validation in this approach?
That is up to you. If you use a stub resolver that has DNSSEC support (like stubby) you have DNSSEC validation.
- 1 for DoT and DoH over tor, especially due to the DoH
implementation that is available in firefox (it would still require work on stream isolation and caching risks to ensure the usual first party isolation). In terms of achieving a big improvement on tor browser users in the context of DNS this would be the most effective path to spend coding resources on in my opinion.
It seems that Firefox's DoH implementation does not employ DNSSEC validation, see [2]. They trust CF doing it for them. Be careful here.
I'm aware that firefox does not perform DNSSEC validation. I don't think the tor project would enable DNSSEC in Tor Browser without a good use-case or a (future) TLS extensions solving the latency issue. Since DANE for HTTPS does not appear to be a thing and there is no DANE support in firefox I'm also wondering about the specific use-cases for DNSSEC in Tor Browser.
Furthermore, there are privacy concerns about additional metadata regarding the use of DoH (agent headers,
solved since https://bugzilla.mozilla.org/show_bug.cgi?id=1543201
language settings,
solved since https://bugzilla.mozilla.org/show_bug.cgi?id=1544724
and cookies)
I don't think firefox sends cookies in DoH requests.
I'm still curious about the underlying threat model and use-cases (my first questions in this thread), since that would help with trying to understand what you are trying to achieve.
kind regards, nusenu
On Sun, 2020-05-24 at 19:01 +0200, nusenu wrote:
Christian Hofer:
On Sat, 2020-05-16 at 01:37 +0200, nusenu wrote:
Alexander Færøy:
I wonder if it would make more sense to have an onion-aware DNSSEC-enabled resolver *outside* of the Tor binary and have a way for Tor to query an external tool for DNS lookups.
I'm also in favor of this approach, and you can do this today with no code changes to tor at all.
CF demonstrated it even before DoH/RFC8484 was finalized: https://blog.cloudflare.com/welcome-hidden-resolver/
Do you have DNSSEC validation in this approach?
That is up to you. If you use a stub resolver that has DNSSEC support (like stubby) you have DNSSEC validation.
- 1 for DoT and DoH over tor, especially due to the DoH
implementation that is available in firefox (it would still require work on stream isolation and caching risks to ensure the usual first party isolation). In terms of achieving a big improvement on tor browser users in the context of DNS this would be the most effective path to spend coding resources on in my opinion.
It seems that Firefox's DoH implementation does not employ DNSSEC validation, see [2]. They trust CF doing it for them. Be careful here.
I'm aware that firefox does not perform DNSSEC validation. I don't think the tor project would enable DNSSEC in Tor Browser without a good use-case or a (future) TLS extensions solving the latency issue. Since DANE for HTTPS does not appear to be a thing and there is no DANE support in firefox I'm also wondering about the specific use-cases for DNSSEC in Tor Browser.
Furthermore, there are privacy concerns about additional metadata regarding the use of DoH (agent headers,
solved since https://bugzilla.mozilla.org/show_bug.cgi?id=1543201
language settings,
solved since https://bugzilla.mozilla.org/show_bug.cgi?id=1544724
Well done!
and cookies)
I don't think firefox sends cookies in DoH requests.
I'm still curious about the underlying threat model and use-cases (my first questions in this thread), since that would help with trying to understand what you are trying to achieve.
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.
Maybe this is not a real concern, otherwise you might have already considered it.
kind regards, nusenu
BR Christian
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
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?
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.
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.
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)
There are a few issues to solve along that path.
kind regards, nusenu
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
However, thinking about it, DNSSEC might be useful for caching DNS records on the client side.
caching has privacy implications and is therefore a risk.
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)?
based on statements from Roger about what is the max. acceptable size of a single exit operator in terms of fraction of the network I'd assume that it is somewhat ok to use a single resolver operator for about 5% of the total exit traffic. That means we need at least 20 resolver operators, preferably 30. We could come up with requirements for them (Mozilla's DoH resolver requirements is a start) and make use of public privacy aware DNS resolver operators that meet the requirements. It might also be possible to ask well established exit operators to run DoH endpoints on their resolvers. This would have positive performance implications and increase the number of available DoH servers.
but finding resolvers is probably one of the smaller issues when compared to getting everything implemented in firefox/tor browser. Current versions do not even allow to set more than one resolver URL.
kind regards, nusenu
On Tue, 2020-06-09 at 23:54 +0200, nusenu wrote:
However, thinking about it, DNSSEC might be useful for caching DNS records on the client side.
caching has privacy implications and is therefore a risk.
So you are saying that caching is not an option in any case, right? Can I kindly ask you to elaborate on this? You don't have to write a long answer. A link pointing me to the answer would be more than enough. I just want to understand the reason behind this.
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)?
based on statements from Roger about what is the max. acceptable size of a single exit operator in terms of fraction of the network I'd assume that it is somewhat ok to use a single resolver operator for about 5% of the total exit traffic. That means we need at least 20 resolver operators, preferably 30. We could come up with requirements for them (Mozilla's DoH resolver requirements is a start) and make use of public privacy aware DNS resolver operators that meet the requirements. It might also be possible to ask well established exit operators to run DoH endpoints on their resolvers. This would have positive performance implications and increase the number of available DoH servers.
but finding resolvers is probably one of the smaller issues when compared to getting everything implemented in firefox/tor browser. Current versions do not even allow to set more than one resolver URL.
I see. Are there any tickets or design proposals I can contribute to?
Since you have no comments on my suggestion for an alternative approach, I assume that it is not worth to compare it to DoH, right?
kind regards, nusenu
BR Christian
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Christian Hofer:
On Tue, 2020-06-09 at 23:54 +0200, nusenu wrote:
However, thinking about it, DNSSEC might be useful for caching DNS records on the client side.
caching has privacy implications and is therefore a risk.
So you are saying that caching is not an option in any case, right? Can I kindly ask you to elaborate on this? You don't have to write a long answer. A link pointing me to the answer would be more than enough. I just want to understand the reason behind this.
You can use cache but it must address the linkability risk by scoping the cache usage. With DoH the browser has access to TTL values from DNS records, so caching is somewhat easier for the browser as it used to be.
keywords and pointers: unlinkability first party isolation https://www.torproject.org/projects/torbrowser/design/
but finding resolvers is probably one of the smaller issues when compared to getting everything implemented in firefox/tor browser. Current versions do not even allow to set more than one resolver URL.
I see. Are there any tickets or design proposals I can contribute to?
I haven't put my ideas into a specification yet, but it looks like there is a good reason to write a spec now.
A next step - before anything else - could be to ask Tor Browser people if there are any DoH plans yet, I did so back in 2018 and will follow up on that right after this email.
Since you have no comments on my suggestion for an alternative approach, I assume that it is not worth to compare it to DoH, right?
to quote my vision:
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)
This vision somewhat implies the use of DoH, since Firefox requires DoH for ESNI (unless one wants to implement that in an additional Firefox patch). A second good reason for DoH over some other option: DoH is a specified protocol with public implementations and public services/service providers. This helps with resolver diversity, availability and gives us more options when choosing resolvers.
kind regards, nusenu
-
Alexander Færøy -
Christian Hofer -
David Goulet -
Jeremy Rand -
Nick Mathewson -
nusenu -
Roger Dingledine