-----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. -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJY4rf2AAoJELPy0WV4bWVwviQP+wSz9/L8czef+L+viSIIrrtv BOp32fysFWw1HijQ/42IoELPhkkzsHjek4IuW6Hn3VHGYs9vJ+rQ9aOcCMGNGD/f f7ktcw3upH/UHiFPp2S0LeNqaoup8qvUQxG/AeP5R20gD/660ZXuIVl4uOaOu5HJ IaghO9ZpzSF695H97hf7bz3H3Wrmch8tjC+FZ+SwWdgqGa4ijjZbTvkypcPEZ6YI YQ22PmoQQWQBbe9JLujLa46PwRWU+UKsppmQYi7dY9K7aO7/J9eKQnOLkUWtdKrN WjtJMV+V4oL/g4IiJrPs5n82pGSvpFi/dMrakoGq2w+v1dJolz/lSGUj7+sWVQZl iqoq6c+l7MjKNynmj/Yn8IquhhwRmVAj4sjV+2jUeVmAf/tHDCBsDYvIDcDeIblu j6y9e7ePTlMTpuxbZ7OKJjsWgGF5+yumWHPtJYs9uBoATeYDM6+Gxm73rDZxRVCl +KGN1jMuREA9N1ZiWuK/ueeeZWGHii4L4UWvdK0qriSvc0HxaQeCGlovEDfO8btO ZDfq9P6USEZywqFyzjzvOUwxnhihwNMdFiSt0RfxLuX34H6POvFYHhw85ESlliY8 0RPjHW6GZywNuOgpYDu9kPS6HPFhXUtok708Jmc926ctX2TT0CJlK6Fl3R2kZGCa nOLHLSYVmkehj6u3RdBf =Hz3g -----END PGP SIGNATURE-----
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. -- Jesse Victors Developer of the Onion Name System
-----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. -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJY5wi/AAoJELPy0WV4bWVwp78P/jd8xte9hgEZiVIJ1nSgIV7Q Yo3NNZpSlDyeyPr2XktGm9JUsBGgMjN+D+oIQcilEiaIAuufrdNW8R4n00VoJMgQ yAHB42UNRJXq1W9+Y7TgrDHjbzsea4fNSZSA5e2kHqOaxPV5fK/qX7xKC8/fPHsf 329qk8BPcGVe2SkLkJqNKBW5D5cBA54HcMENV6w/6Vos64OD/ZKUOclSHcubtwWz kYRn6ERv67/dHRV8M58WYewA/lFvyvMCSLyyZbfJXuJEsV6wlpFIxWbJezps80EU coiCunGeu0TCj6Ae0lVtr8cuyMCN4WyCs7C4BkdiuCrLwri+IW8vR8LeP8fLjQCa ImnfgxIOdxiHti77UPzWjEPGKerdJi/gVF4NmJ2XL2qJEv0rr4hnaEn3LKTHAEQm 0k0EjDXGaMgNhSS5y67PLW5bW909uISrCIYnNAOfSi3vRwCfYusY3N0P6seH78R9 VNhS/bnUCTEfD3CJFvZD2coUbpvG/vXW5OI8D02Ro+3FJqvcbbkXXhimK0d9R65V s96ckSAmI+m0VD7FO3hGW0BUzGdzVAJIsEfLIwUCqasQ7ugwbawfh0JvjYreM14T ZmnM9usdNPcgE+uRnZbHpHG6n3GcOIWc1ShhoCHvzaF3zF8+UWPMElwmFA4XZCo2 2YgPFCAuFfSfQapZxrX9 =iXyt -----END PGP SIGNATURE-----
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 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.
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/ -- meejah
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. -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJZBDotAAoJELPy0WV4bWVwyCgQAIinmd5pBqf86vq4ae2N9KwX /IFstwBZFuD7QSzBeFyQI1n+tP76OHM7dSpPPvZZfz8ksuTLwjdYJBkSDMGoiWzS KjAFcFK4VBCmPhkq6nd97nqSYXiqlyoZMKCAwE6Yxg4YV6a0mLnfkNYdIpRwXgXa EkL75FxsYFFWPztLBa63vZlJcuxfJ4lBtZDdhiRunnQh+KXwHmA2fukc8yqxs5lF tnE2Mzb06bI3KYmcjmpi+Zb0u2QYNtnY5jPTN5LNu4XeOcpvKieHpqEDHTBVzArR 3zXpmvmvWlPcT6KzWp4kaNM+f76Q/uXbetVfyPPPUlxR3fKbRGjJ9owpGpcR/Nhb YnpG0jSZXKu5j+zN9mXM+SB+lBVqOGwwF5ae2oIRe6H0gG53il7jv3gQCSh/EZO7 9harqftv9LqfKtPZpRjzIWGv2DSriy2wPJsKwsL1o3c/DrEbnbbh/cEIs+RMlijF fjP2daO9DVKnAClB8YcZw0cgWc4xZ5EcZnF0FPsV4ZWREgG1UIzUm+fV04HPruYB k5OX5T4HdNSU0lJJY7H4P6VHbpr3i73PnDBJsUvOM2cFQattxGCMxGzF5pDp+wIC R2dFLASWtiQOL4alyqUxP9aoR7DJcvYm7jThe1aNjyyN880wbYCJnUYEoQa0k10t DBAecAT+HDKuZt7WklMm =84wv -----END PGP SIGNATURE-----
participants (5)
-
George Kadianakis -
Hugo Landau -
Jeremy Rand -
Jesse V -
meejah