- tor-dev - lists.torproject.org

Comments on proposal 279 (Name API)
by Nick Mathewson 09 Apr '17

09 Apr '17

Hi ! I'll make some comments here on the draft onion naming API at https://gitweb.torproject.org/torspec.git/tree/proposals/279-naming-layer-a… (Some of these are probably things you already meant, or already said elsewhere.) Section 2.1 and elsewhere: I suggest that we require all address suffixes to end with .onion; other TLDs are not reserved like .onion is, and maybe we shouldn't squat any we haven't squatted already. I think we might also want to have all output addresses end with .onion too. I suggest also that we might want to reserve part of the namespace for standardized namespaces and some for experimental or local ones. Like, if we standardize on namecoin that could be .bit.onion, but if we don't, it could be .bit.x.onion. I finally suggest that we distinguish names that are supposed to be global from ones that aren't. Section 2.3: How about we require that the suffixes be distinct? If we do that, we can drop this "priority" business and we can make the system's behavior much easier to understand and explain. Let's require that the TLDs actually begin with a dot. (That is, I think that ".foo.onion" can include "bar.foo.onion", but I don't like the idea of "foo.onion" including "barfoo.onion".) Section 2.3.1: Does the algorithm apply recursively? That is, can more then one plugin rewrite the same address, or can one plugin rewrite its own output? (I would suggest "no".) I think there should be a way for a plugin to say "This address definitely does not exist" and stop resolution. Otherwise no plugin can be authoritative over a TLD. Section 2.5.1: Is the algorithm allowed to produce non-onion addresses? Should it be? Must query IDs be unique? Over what scope must they be unique? Who enforces that? May query IDs be negative? Can they be arbitrarily large? I think result should indeed be optional on failure. Section 2.5.1 and 2.5.2: We should specify what exactly clients and plugins will do if they receive an unrecognized message, or a malformed message. Section 2.5.3. See security notes on caching below; client-side caching can lead to undesirable results. As noted above, I agree with requiring all result addresses to be .onion. Section 3.1: I prefer the "put everything under .onion" option. I also think that we should require that the second-level domain be 10 characters or less, to avoid confusion with existing onion addresses. General questions: I know we've done stdout/stdin for communication before, but I wonder if we should consider how well it's worked for us. The portability on Windows can be kind of hard. Two alternatives are TCP and named pipes. Another alternative might be just using the DNS protocol and asking for some kind of "ONION_CNAME" record. (DNS is ugly, but at least it's nice and standard.) Security notes: I'd like to know what the browser people think about the risks here of (eg) probing to see whether the user has certain extensions installed or names mapped. Maybe .hosts.onion should only be allowed in the address bar, not in HREF attributes et al? We might want to think about cache-related timing attacks here. Perhaps we should have a "no caching" rule. We should probably add a security notes section for how to write plugins that aren't dangerous: a bad plugin potentially breaks user anonymity.

7 10

Reverse Naming Proposals?
by grarpamp 09 Apr '17

09 Apr '17

These recent naming proposals on list, for forward naming 'string --> onion, 1:1', I think. Is anyone working on doing reverse naming, 'onion --> string, 1:1' ? With links to such work?

1 0

Adding Single Onion Service support to Bitcoin Core
by James Evans 08 Apr '17

08 Apr '17

Core is preparing to support this new tor feature. Any helpful suggestions would be appreciated. :) https://github.com/bitcoin/bitcoin/issues/9836 https://github.com/bitcoin/bitcoin/pull/10161 Thanks for all the great onion work! James

1 0

minimizing traffic for IoT Tor node over 3G/LTE
by Razvan Dragomirescu 08 Apr '17

08 Apr '17

Hello, I am working on a project to create very small Tor nodes on embedded devices connected over LTE or 3G. I have it working fine with OpenWRT and just 128MB of RAM, but the main issue is now the amount of data needed to download the consensus. The consensus files appear to be around 2.3MB at the moment and I think the default is to re-download every 3 hours, so that's 18.4MB/day or 552MB/month. Is there any way to reduce this while still maintaining good citizenship on the Tor network? Are there any recommended options for low-bandwidth nodes? Thank you, Razvan -- Razvan Dragomirescu Chief Technology Officer Cayenne Graphics SRL

2 3

Re: [tor-dev] Comments on proposal 279 (Name API)
by str4d 07 Apr '17

07 Apr '17

On 04/06/2017 09:13 AM, Jeremy Rand wrote: > Hi Nick! > > Nick Mathewson: >> Section 2.1 and elsewhere: > >> I suggest that we require all address suffixes to end with .onion; >> other TLDs are not reserved like .onion is, and maybe we shouldn't >> squat any we haven't squatted already. > > FWIW it's not at all clear to me that this is a concern that IETF or > ICANN will care about. Most DNS recursive servers (e.g. Unbound) > allow squatting on arbitrary TLD's (this is often used for corporate > systems that use internal TLD's, but we use it for Namecoin as well), > and to my knowledge no one has complained to Unbound about the ability > to misuse this. Then you haven't been reading the DNSOP working group's mailing list - the IETF certainly cares. I recommend searching for ".onion", "special-use", "sutld", or "alt-tld" on their ML viewer [0] and reading the (extensive) back-history of these discussions. See below for a link to my earlier comments on this tor-dev thread [1], as well as several IETF drafts you may wish to read and comment on [2-3]. Cheers, str4d [0] https://mailarchive.ietf.org/arch/search/?email_list=dnsop [1] https://lists.torproject.org/pipermail/tor-dev/2017-April/012153.html [2] https://tools.ietf.org/html/draft-ietf-dnsop-sutld-ps-03 [3] https://tools.ietf.org/html/draft-ietf-dnsop-alt-tld-08

1 0

GSoC: Support all kinds of DNS queries
by Daniel Achleitner 07 Apr '17

07 Apr '17

Hi everyone, I'm a Software Engineering master's student at TU Wien, Austria, with a recent focus on computer security and privacy issues. I am interested in participating in GSoC 2017, particularily in the task to support all kinds of DNS queries via Tor [1]. I've seen the mailing list discussions of 2012 and read the resulting proposition 219 [2]. What do you think, which parts of it (if any) would need to be adapted for DNS in 2017? My current impression is that not much has changed, particularily regarding DNSSEC support and deployment. As of now, the proposal looks fairly complete with few questions remaining, the biggest research task being how to utilize libunbound for query/response parsing and construction. Implementing the RELAY DNS cells then seems fairly straightforward. Unit/integration tests and some fuzzing would be a good idea. The problem of reducing DNSSEC roundtrips (serialization) to be investigated in a later phase, I would say. Is a separate AXFR tool still something that is desired? I have no experience with zone transfers -- can't the existing tooling just be used over a normal TCP conn through Tor? This project idea would make a good match to my thesis in progress, for which I am researching and evaluating privacy-improving DNS tools in the context of Tor (DNSCrypt, DNS-over-TLS) [3], inspired by the awesome paper on DNS correlation [4]. For example, I recently built a SOCKS-to-SOCKS translator which allows to resolve hostnames using a resolver of choice, e.g. using DNSCrypt with TBB. Looking forward to hearing your thoughts, concerns and opinions! Best regards, Daniel IRC handle on OFTC: idealchain [1]: https://www.torproject.org/getinvolved/volunteer.html.en#supportAllDNS [2]: https://gitweb.torproject.org/torspec.git/tree/proposals/219-expanded-dns.t… [3]: My work-in-progress mindmap about DNS Privacy (not related to prop219): https://drive.google.com/open?id=0B3d38csDsjwudDJOUjRleE93bjQ [4]: https://nymity.ch/dns-traffic-correlation/tor-dns.pdf

2 3

Rethinking Bad Exit Defences: Highlighting insecure and sensitive content in Tor Browser
by Donncha O'Cearbhaill 06 Apr '17

06 Apr '17

Hi all, The Tor bad-relay team regularly detects malicious exit relays which are actively manipulating Tor traffic. These attackers appear financial motivated and have primarily been observed modifying Bitcoin and onion address which are displayed on non-HTTPS web pages. Increasingly these attackers are becoming more selective in their targeting. Some attackers are only targeting a handful of pre-configured pages. As a result, we often rely on Tor users to report bad exits and the URLs which are being targeted. In Firefox 51, Mozilla started to highlight HTTP pages containing password form fields as insecure [1]. This UI clearly and directly highlights the risk involved in communicating sensitive data over HTTP. I'd like to investigate ways that we can extend a similar UI to Tor Browser which highlight Bitcoin and onion addressed served over HTTP. I understand that implementing this type of Bitcoin and onion address detection would be less reliable than Firefox's password field detection. However even if unreliable it could increase safety and increase user awareness about the risks of non-secure transports. There is certainly significant design work that needs to be done to implement this feature. For example, .onion origins need be treated as secure, but only if they don't included resources from non-secure origins. We would also need to make the onion/bitcoin address detection reliable against active obfuscation attempts by malicious exits. I'd like to hear any and all feedback, suggestions or criticism of this proposal. Kind Regards, Donncha [1] https://blog.mozilla.org/security/2017/01/20/communicating-the-dangers-of-n…

7 8

Counter-RAPTOR Paper
by Yixin Sun 06 Apr '17

06 Apr '17

Hi all, Our proposed defenses (Counter-RAPTOR) against active routing attacks on Tor will soon appear at IEEE S&P in May. It's also available here: https://arxiv.org/abs/1704.00843 In short, we have two lines of defenses: (1) Entry Guard Selection (proactive defense, https://github.com/inspire-group/Counter-Raptor-Tor-Client) (2) BGP Monitoring on Tor relays (reactive defense, in progress of making it public) Please let us know if you have any questions/comments. Thanks! Yixin

2 1

"Anomalous keys in Tor relays" technical report now available
by Laura M. Roberts 05 Apr '17

05 Apr '17

Hello, Tor devs! We have just published a (not yet peer-reviewed) technical report entitled "Anomalous keys in Tor relays." https://nymity.ch/anomalous-tor-keys/ The project was inspired by the "Mining Your P's and Q's" paper from Heninger et. al., and in it, we take a closer look at the RSA keys used in Tor since 2005. We found that entities had purposely created anomalous keys in order to attack Tor's onion services and that researchers had inadvertently created weak keys while conducting experiments on Tor. (None of the weak keys we found are affecting the current Tor network.) We welcome your questions and feedback! Regards, George, Claudia, Laura, & Philipp

1 0

Re: [tor-dev] Comments on proposal 279 (Name API)
by str4d 04 Apr '17

04 Apr '17

On 04/04/2017 12:50 AM, Nick Mathewson wrote: > On Mon, Apr 3, 2017 at 8:20 AM, George Kadianakis <desnacked(a)riseup.net> wrote: >> Nick Mathewson <nickm(a)torproject.org> writes: >>> Section 2.1 and elsewhere: >>> >>> I suggest that we require all address suffixes to end with .onion; >>> other TLDs are not reserved like .onion is, and maybe we shouldn't >>> squat any we haven't squatted already. I think we might also want to >>> have all output addresses end with .onion too. >>> >>> I suggest also that we might want to reserve part of the namespace >>> for standardized namespaces and some for experimental or local ones. >>> Like, if we standardize on namecoin that could be .bit.onion, but if >>> we don't, it could be .bit.x.onion. I2P has been doing this for years with *.b32.i2p for unique identifiers vs *.i2p for hosts.txt-style naming, and I'm planning on writing an I2P proposal to create a formal registry of 2LDs that implementations need to know about, so we have the ability to expand in future under the .i2p TLD. So I don't think it's a stretch for users to understand (although I have other concerns, see below), and I'd be keen to have a common standard for specifying subdomains that we can use for interoperability :) >>> >> >> I have mixed feelings about keeping the .onion suffix. >> >> One one hand it seems like The Right Thing to do, since we managed to >> get .onion standarized in the IETF which comes with various >> benefits. Also, starting to squat other tlds arbitrarily seems like a >> silly thing to do. This is the safest space for Tor to work in from a technical perspective. More specifically, I've been following discussion in DNSOP ever since the original special-use names draft (containing .onion, .i2p etc) was posted, and there is no way that the IETF is going to standardise any new TLD for non-DNS (see below). It's increasingly unlikely that the non-.onion TLDs in the draft will either (without industry support like .onion had), so no CA-supported SSL certs for I2P :( >> >> However, I also dislike asking users to visit something.bit.onion >> instead of something.bit, since people are not used to the second tld >> having a semantic meaning, and I can imagine people getting very >> confused about what it means. There's also the problem of transport-agnosticism. Assume there's some FOOnet that is created for naming that we all decide we want to use. Users would probably expect that FOOnet names all exist in the same space, which would not be the case if we had *.foo.onion, *.foo.i2p, etc. I'm thinking along the lines of IPv4 vs IPv6, where you can have a DNS name delegate to both via A and AAAA records; you wouldn't want the name changing just because the underlying transport changed. > > Indeed. And I'm not only concerned about people becoming confused: I > am also worried about confused programs. > > Right now, it is easy to answer the question "will Tor handle this > address specially" -- the only special addresses are the ones ending > with ".onion", and the legacy suffices ".exit" and ".noconnect" as > documented as address-spec.txt. But if we allowed arbitrary TLDs in > this proposal, then _any_ hostname would potentially be an address > that Tor would handle specially. > There is a draft currently in working-group last call that will specify a .alt TLD (or possibly .alt.arpa, it's still being debated [1]), that future non-DNS names will have to be under. Part of the proposed benefit is that with a standard TLD, DNS resolvers can just stub out that entire namespace, ie. if fqdn.endswith('.alt'): do_non_dns_lookup(fqdn) else: gethostbyname(fqdn) Presumably, browsers would do so as well. So it's possible that you could have *.foo.alt as the URI, but only *.foo is displayed in the browser (along with some chrome indicating it is non-DNS), similar to how only the base domain name is shown for some URIs (IIRC that's an SSL cert verification thing). The question then is how a browser would handle *.foo being typed in. You wouldn't want to query DNS and then try *.foo.alt afterwards, as that would be terrible for privacy, but if they tried *.foo.alt first, and didn't have FOOnet installed, should they try *.foo in the DNS? The browser either needs to know the full contents of *.alt (which is not possibly because by design it will have no official registration), or every registered TLD in DNS (which won't ever be added as a restriction because of various legacy local-net vendor TLDs like *.home). So with this approach, it's likely that .alt would need to stick around. Lots to think about here... str4d [0] https://tools.ietf.org/html/draft-ietf-dnsop-alt-tld-08 [1] https://www.ietf.org/mail-archive/web/dnsop/current/msg19983.html

1 0