-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Hello!
Maybe this topic has already been brought up, but in case it hasn't, I'll do so. I notice that Prop279 (onion naming API) defines its own API rather than using DNS. I guess that this is because of security concerns about the centralization of the DNS.
However, in case you're unaware, Namecoin is designed to interoperate with DNS. Let's say that, hypothetically, Tor defined a DNS-based naming system for onion services, where "_tor.example.com" had a TXT record that was verified with DNSSEC in order to make Tor direct "example.com" to whatever that TXT record had. If this were done, Namecoin would be able to produce the necessary TXT record and DNSSEC signatures, via the standard DNS protocol, using an authoritative nameserver that runs on localhost. (The DNSSEC keys used would be unique per user, generated on installation.) Indeed, this is how we're planning to interoperate with non-proxy-based Internet applications.
My guess is that it would be a lot less work on Namecoin's end if such a system were used with Tor rather than a separate naming API. It's unclear to me how this would affect other naming systems such as GNS (does GNS interoperate with clients that use DNS?), and it's also unclear to me whether this would produce extra work for the Tor developers (maybe DNS adds extra attack surface that would need to be mitigated somehow, or maybe there would be complexity in implementing stream isolation?).
Anyway, just figured I'd bring up the topic so that everyone's on the same page regarding figuring out whether it's a good idea.
Cheers, - -- - -Jeremy Rand Lead Application Engineer at Namecoin Mobile email: jeremyrandmobile@airmail.cc Mobile PGP: 2158 0643 C13B B40F B0FD 5854 B007 A32D AB44 3D9C Send non-security-critical things to my Mobile with PGP. Please don't send me unencrypted messages. My business email jeremy@veclabs.net is having technical issues at the moment.
On 04/03/2017 05:01 PM, Jeremy Rand wrote:
Maybe this topic has already been brought up, but in case it hasn't, I'll do so. I notice that Prop279 (onion naming API) defines its own API rather than using DNS. I guess that this is because of security concerns about the centralization of the DNS.
Hi Jeremy,
I believe that the general idea with prop279 is simply to introduce an API for resolving pseudo-TLDs before they were sent through the Tor network. How that is done is entirely dependent on the naming system.
For example, if a user typed in example.bit into a Namecoin-enabled Tor browser, the software could then perform your proposed DNS lookup and rewrite the request before turning it over to the tor binary. In my case, my OnioNS software rewrites .tor to .onion, since the tor binary knows how to handle .onion. At the moment, this is a bit hacky because the software has connect with tor's control port, manually review and process each lookup, rewrite the the request, and then tell tor to connect it with a circuit. Prop 279 is designed to make this much easier and avoid hacky solutions.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Jesse V:
On 04/03/2017 05:01 PM, Jeremy Rand wrote:
Maybe this topic has already been brought up, but in case it hasn't, I'll do so. I notice that Prop279 (onion naming API) defines its own API rather than using DNS. I guess that this is because of security concerns about the centralization of the DNS.
Hi Jeremy,
I believe that the general idea with prop279 is simply to introduce an API for resolving pseudo-TLDs before they were sent through the Tor network. How that is done is entirely dependent on the naming system.
For example, if a user typed in example.bit into a Namecoin-enabled Tor browser, the software could then perform your proposed DNS lookup and rewrite the request before turning it over to the tor binary. In my case, my OnioNS software rewrites .tor to .onion, since the tor binary knows how to handle .onion. At the moment, this is a bit hacky because the software has connect with tor's control port, manually review and process each lookup, rewrite the the request, and then tell tor to connect it with a circuit. Prop 279 is designed to make this much easier and avoid hacky solutions.
Hi Jesse,
Yes, I understand that the goal is to provide an abstraction layer for naming systems that doesn't rely on control port hacks -- and that's great! My primary inquiry here is about whether the DNS protocol might be a better-suited protocol for Tor to use for talking to naming systems, rather than a Tor-specific protocol as is proposed now. I don't hold a strong opinion on this; I'm mostly just curious whether it was considered, and if so, what led to the decision not to use it.
Cheers, - -- - -Jeremy Rand Lead Application Engineer at Namecoin Mobile email: jeremyrandmobile@airmail.cc Mobile PGP: 2158 0643 C13B B40F B0FD 5854 B007 A32D AB44 3D9C Send non-security-critical things to my Mobile with PGP. Please don't send me unencrypted messages. My business email jeremy@veclabs.net is having technical issues at the moment.
Jeremy Rand jeremyrand@airmail.cc writes:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Hello!
Maybe this topic has already been brought up, but in case it hasn't, I'll do so. I notice that Prop279 (onion naming API) defines its own API rather than using DNS. I guess that this is because of security concerns about the centralization of the DNS.
However, in case you're unaware, Namecoin is designed to interoperate with DNS. Let's say that, hypothetically, Tor defined a DNS-based naming system for onion services, where "_tor.example.com" had a TXT record that was verified with DNSSEC in order to make Tor direct "example.com" to whatever that TXT record had. If this were done, Namecoin would be able to produce the necessary TXT record and DNSSEC signatures, via the standard DNS protocol, using an authoritative nameserver that runs on localhost. (The DNSSEC keys used would be unique per user, generated on installation.) Indeed, this is how we're planning to interoperate with non-proxy-based Internet applications.
My guess is that it would be a lot less work on Namecoin's end if such a system were used with Tor rather than a separate naming API. It's unclear to me how this would affect other naming systems such as GNS (does GNS interoperate with clients that use DNS?), and it's also unclear to me whether this would produce extra work for the Tor developers (maybe DNS adds extra attack surface that would need to be mitigated somehow, or maybe there would be complexity in implementing stream isolation?).
Anyway, just figured I'd bring up the topic so that everyone's on the same page regarding figuring out whether it's a good idea.
Hmmm,
using DNS for the query/resolve part of the NS API might actually be a reasonable approach for Tor. Prop279 is currently doing query/resolves using stdin/stdout messages but people have rightly pointed out that this sucks in mobile platforms: https://lists.torproject.org/pipermail/tor-dev/2016-October/011516.html https://lists.torproject.org/pipermail/tor-dev/2017-March/012077.html
I'm not sure if TCP and DNS is the right approach here, but it seems like worth exploring further.
Some thoughts:
- If we replace the stdin/stdout protocol with a DNS client/server, this means that any interested in name system would also have to implement a DNS server as part of its NS API wrapper.
This seems harder to prototype than an stdin/stdout protocol. I wonder if a library could be made to make it easier for name systems to do this (and imagine that in our case, a name system might be something as simple as a local hosts file; not necessarily something as big as Namecoin).
- If we manage to replace the stdin/stdout protocol with DNS, I wonder what can be done about the environment variables part of the protocol, which apparently also sucks for mobile platforms.
In the current prop279, environment variables are set by Tor before it execve()s the guest name system. They are used to pass arbitrary options to the name system, instruct it on where it should store files, and let it know of ControlPort configuration etc.
- A big part of the prop279 spec would have to be rewritten to port it to the DNS protocol. I doubt I have time to do this in the short-term, especially given how clueless I am wrt the DNS protocol. Ideally someone would take over this proposal and fix it up....
Also, is there a spec for how Namecoin uses DNS to do stuff?
Thanks for the input :)
George Kadianakis:
Hmmm,
using DNS for the query/resolve part of the NS API might actually be a reasonable approach for Tor. Prop279 is currently doing query/resolves using stdin/stdout messages but people have rightly pointed out that this sucks in mobile platforms: https://lists.torproject.org/pipermail/tor-dev/2016-October/011516.html https://lists.torproject.org/pipermail/tor-dev/2017-March/012077.html
Interesting, I wasn't aware of the mobile platform issues with stdin/stdout, but that does make sense. Seems like DNS would be one way to improve that situation.
I'm not sure if TCP and DNS is the right approach here, but it seems like worth exploring further.
Some thoughts:
If we replace the stdin/stdout protocol with a DNS client/server, this means that any interested in name system would also have to implement a DNS server as part of its NS API wrapper.
This seems harder to prototype than an stdin/stdout protocol. I wonder if a library could be made to make it easier for name systems to do this (and imagine that in our case, a name system might be something as simple as a local hosts file; not necessarily something as big as Namecoin).
One of the Namecoin developers, Hugo Landau, wrote a Golang library that might be helpful for this. The library is at https://github.com/hlandau/madns , and the Namecoin authoritative DNS server that uses it is https://github.com/hlandau/ncdns . I'll point Hugo to this thread so that he can elaborate on anything I've left out and/or answer questions. DNS is certainly a more complex protocol than stdin/stdout. AFAIK there aren't any good Python libraries for this kind of thing (at least, none that support DNSSEC), though it's been a year or so since I last looked.
If we manage to replace the stdin/stdout protocol with DNS, I wonder what can be done about the environment variables part of the protocol, which apparently also sucks for mobile platforms.
In the current prop279, environment variables are set by Tor before it execve()s the guest name system. They are used to pass arbitrary options to the name system, instruct it on where it should store files, and let it know of ControlPort configuration etc.
I'm honestly not sure on this one.
- A big part of the prop279 spec would have to be rewritten to port it to the DNS protocol. I doubt I have time to do this in the short-term, especially given how clueless I am wrt the DNS protocol. Ideally someone would take over this proposal and fix it up....
I can ask Hugo if he'd be willing to help out with the DNS end of things, but I don't think he has intimate familiarity with Tor, so he probably wouldn't be able to do all of it (assuming that he has the time available, which I am unsure of).
Also, is there a spec for how Namecoin uses DNS to do stuff?
We have a spec that describes how a Namecoin JSON object is converted into a set of DNS records: https://github.com/ifa-wg/proposals/blob/master/ifa-0001.md . (That URL will probably change in the future.) We then use ncdns (see above) to run an authoritative DNS server for .bit, which is signed with a per-machine DNSSEC key generated at install time. We then use a local Unbound as the main DNS server for the user, configured to use ncdns as a stub zone.
Hypothetically, Tor could act as a recursive DNS server (substituting for Unbound), and allow stub zones to be specified similarly to how Unbound does it. In Namecoin's case, the .bit and .bit.onion stub zones would point to a local ncdns installation.
It's worth noting that some Namecoin node types will generate network traffic to do the lookup. This should support stream isolation based on what stream caused the Namecoin lookup. Hugo tells me that one plausible way to communicate this info to ncdns over the DNS protocol would be edns.
I think there are probably 2 orthogonal questions: (1) should DNS be the standard abstraction protocol used for Tor naming, and (2) should Namecoin naming in Tor be implemented using DNS? If (1) is "no" but (2) is "yes", then we would still get the benefits of DNS and DNSSEC interoperability, although not the benefits for mobile platform compatibility.
Also, to throw another idea out there that plausibly might be worth thinking about in this discussion: it might be useful to have a mechanism for a Tor exit relay to do the Namecoin lookup and return the record along with a merkle proof of blockchain inclusion, similarly to how exit relays do DNS lookups now. This might reduce latency by one round-trip in some cases, since the exit relay could open a connection to the .bit website before the merkle proof is checked. It also would mean that we would need a protocol for Tor send that merkle proof to Namecoin for validation. I have no idea whether this functionality would also be useful for OnioNS and GNS, but I guess that it would be beneficial for DNSSEC.
Anyway, I don't have a strong view on whether using DNS as the abstraction protocol is the right choice -- but it's good to have the discussion, I think.
Cheers!
Jeremy Rand jeremyrand@airmail.cc writes:
AFAIK there aren't any good Python libraries for this kind of thing (at least, none that support DNSSEC), though it's been a year or so since I last looked.
Twisted has a DNS server and client implementation. I'm not sure where it stands on DNSSEC support, although a quick grep does indicate some "dnssec"-related attributes. See:
https://twistedmatrix.com/trac/wiki/TwistedNames https://twistedmatrix.com/documents/current/names/
After giving it some thought, I think Tor should use a Tor-specific protocol to interface with name plugins, not DNS.
My reasoning is as follows: the Tor daemon knows what it wants and is designed to source specific data from a name plugin. Where Tor specifies a custom protocol for this, this will match perfectly the type of queries and type of responses which Tor needs to ultimately obtain and convert to some corresponding internal in-memory representation.
As such, forcing this made-for-Tor format to be marshalled into a pre-existing format, namely that of DNS queries and responses, can only ever reduce the power and flexibility of the plugin interface. It only creates the potential for impedence discontinuities, and also creates a substantial nuisance and implementation barrier for plugins which are intended only for use with the Tor daemon. These plugins would need to source a DNS packet marshalling/unmarshalling library, which creates an unnecessary barrier to implementation, and both sides of the interface would be marshalling into a format which isn't especially aligned with the internal representations they'd ideally like to be speaking. As such, using DNS here feels rather pointless.
Looking at the Prop279 proposal as it stands, it would be trivial for a plugin that wants to work with DNS packets to convert a query to a DNS packet. As such, I see very little utility to adopting the DNS format for this.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Hugo Landau:
After giving it some thought, I think Tor should use a Tor-specific protocol to interface with name plugins, not DNS.
My reasoning is as follows: the Tor daemon knows what it wants and is designed to source specific data from a name plugin. Where Tor specifies a custom protocol for this, this will match perfectly the type of queries and type of responses which Tor needs to ultimately obtain and convert to some corresponding internal in-memory representation.
As such, forcing this made-for-Tor format to be marshalled into a pre-existing format, namely that of DNS queries and responses, can only ever reduce the power and flexibility of the plugin interface. It only creates the potential for impedence discontinuities, and also creates a substantial nuisance and implementation barrier for plugins which are intended only for use with the Tor daemon. These plugins would need to source a DNS packet marshalling/unmarshalling library, which creates an unnecessary barrier to implementation, and both sides of the interface would be marshalling into a format which isn't especially aligned with the internal representations they'd ideally like to be speaking. As such, using DNS here feels rather pointless.
Looking at the Prop279 proposal as it stands, it would be trivial for a plugin that wants to work with DNS packets to convert a query to a DNS packet. As such, I see very little utility to adopting the DNS format for this.
Thanks Hugo. Yeah, I think you're probably right. In Namecoin's case, it *may* make sense to have a Prop279 provider implementation that uses DNS to talk to Namecoin software, but the difficulty of doing stream isolation properly with DNS and the rather large set of DNS features that have no relevance to many Prop279 providers suggest that it's unwise to force that coupling.
Cheers, - -- - -Jeremy Rand Lead Application Engineer at Namecoin Mobile email: jeremyrandmobile@airmail.cc Mobile OpenPGP: 2158 0643 C13B B40F B0FD 5854 B007 A32D AB44 3D9C Send non-security-critical things to my Mobile with OpenPGP. Please don't send me unencrypted messages. My business email jeremy@veclabs.net is having technical issues at the moment.
-
George Kadianakis -
Hugo Landau -
Jeremy Rand -
Jesse V -
meejah