Nick Mathewson <nickm@torproject.org> writes:

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-ap...

(Some of these are probably things you already meant, or already said elsewhere.)

Thanks for the timely comments! I'm replying to this thread with my thoughts, but I didn't have time to actually fix the proposal. I'll do that in The Future.

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 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. 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. Anyhow, it seems like maintaining the .onion suffix is the right approach here.

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.

Definitely agreed on this simplification suggestion. The priority feature has confused people, and it's not that useful. In the future we could reinstall it if we consider it practical.

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".)

Makes sense.

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".)

Agreed no. We should specify it.

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.

Agreed.

Section 2.5.1:

Is the algorithm allowed to produce non-onion addresses? Should it be?

I'd say no. We should specify this.

Must query IDs be unique? Over what scope must they be unique? Who enforces that?

I think the NS API client should enforce that, and maybe the server should throw an error if it's not unique. We should specify.

May query IDs be negative? Can they be arbitrarily large?

We should specify this too.

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.

Agreed.

Section 2.5.3.

See security notes on caching below; client-side caching can lead to undesirable results.

Agreed.

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.

We should think more about this, but seems reasonable.

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.)

Yup, I think this is an _important_ open part of the proposal that we should figure out sooner than later. Ideally, we should consult Nathan or mtigas or other members of our mobile team. I wish I had done this during the dev meeting... TCP seems like a plausible alternative here. Unfortunately, we will have to invent a new protocol for that tho.

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?

Yep, David F. also mentioned this problem. We should think of how to address it. Browser people might have good ideas here indeed.

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.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 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. Generally I view a pluggable naming system as useful for use cases besides simply human-readable .onion names. It's also useful for any of the various use cases for which people will fiddle with their local DNS setup (including but not limited to: firewalling, ad-blocking, debugging infrastructure, internal naming systems that have nothing to do with .onion, alternate DNS roots like OpenNIC, decentralized naming systems like Namecoin that aren't being used for .onion). Yes, you *could* do this with the control port (OnioNS does this, and Namecoin has an internal beta of this as well that we've chosen not to release because we want to engage on Prop279 to make sure that what we release meets people's needs). But the control port is extremely dangerous to expose to untrusted software, so it makes sense to use a dedicated naming API. Forcing all these other use cases to use a clunkier, less secure setup than the "human-readable .onion names" use case is likely to stifle innovation, lead to duplicated code with different sets of bugs, and/or discourage use of the naming API because software authors don't want to rule out the possibility of exploring other use cases later on. I can totally see a policy making sense that *the naming systems distributed by Tor officially* would only allow .onion as input addresses, but since it sounds like the intent of this proposal is to enable experiments that aren't officially endorsed by Tor, it's not clear to me that such a policy would have much immediate effect. There will probably be a news post posted to the Namecoin website in the next week or so that's relevant to this point, but I won't include it here since it's only reviewed by 3 of the Namecoin developers at this time and I can't rule out needing to make edits to it. I'll provide it in this thread when it's posted. (If for some reason this issue urgently needs to be decided and waiting a week will derail that schedule, let me know and I'll see what I can do.) Also see my next point below:

I think we might also want to have all output addresses end with .onion too.

This definitely makes sense from a UX point of view: everyone already knows what .onion services are, and they have certain expectations for what security properties they provide, so just because the 2nd-level domain isn't a base32 public key shouldn't mean that all those security properties don't apply. Using the 2nd level domain to choose what type of naming system is in use (e.g. .bit.onion) certainly makes sense here. But, there are real use cases where users will want the output address to not be a .onion address: see my point above. I think a perfectly reasonable policy would be: "If the input name is .onion, then the output name must also be .onion; otherwise no restrictions on the output name exist." This preserves the UX properties that people expect from .onion, doesn't restrict the other use cases I mentioned above, and is minimal enough in terms of code and spec complexity that I expect it would be easy to audit.

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 don't have a particularly strong opinion on this, although I do prefer the UX of .bit.onion over .bit.x.onion. How many naming systems are we expecting to actually be used here? I wouldn't expect any collisions to occur here due to the small number of naming systems that are even expressing interest -- no collision with .bit exists even in the wider DNS world 6 years after Namecoin was founded. Is there a threat model component here that I'm not seeing?

I finally suggest that we distinguish names that are supposed to be global from ones that aren't.

This makes sense intuitively; is there a specific motivation for this constraint?

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".)

These make sense.

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 can imagine some use cases where a Namecoin name wants to delegate to an OnioNS name or something like that, but frankly I'm having trouble thinking of a reason why anyone would actually need that, and I can imagine users being confused when encountering something that looks like a Namecoin name but actually has security properties (and technical requirements) derived from both Namecoin and OnioNS. I can also imagine some use cases where a Namecoin name wants to delegate to another Namecoin name, but the extra complexity of handling that use case inside Namecoin seems to be pretty minimal. So I think I agree.

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.

Strongly agree.

Section 2.5.1:

Is the algorithm allowed to produce non-onion addresses? Should it be?

See my comments above.

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.

Curious what the criteria used for choosing 10 is. Certainly 10 is sufficiently small to not be mistaken for a v3 .onion address, so I have no objection here. (I note that len("blockstack")==10, which is the longest name of any of the candidates I'm aware of -- would that be why, or coincidence?)

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.

Been a long time since I messed with Windows and pipes, but last I heard Windows's implementation and API for named pipes has almost nothing in common with POSIX named pipes. Is there an abstraction layer for this that I'm unaware of, or would Tor (and the pluggable naming systems) be responsible for implementing this abstraction? Do such abstractions exist for all the languages that pluggable naming systems will be using?

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.)

I started another thread about this, so I won't duplicate that discussion in this thread.

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?

Does Firefox have a mechanism for applying a same-origin policy to everything that a web page can invoke (e.g. images, which aren't affected by the same-origin policy by default)? If so, maybe it would make sense to apply such a policy to each naming system, so that only Namecoin websites can embed images from Namecoin websites? Maybe a NoScript-style manual whitelisting UI could be used for this? Non-global naming systems like GNS are likely to need additional protections, I would guess. It's not clear to me how much protection we can enforce without annoying users too much.

We might want to think about cache-related timing attacks here. Perhaps we should have a "no caching" rule.

Totally agree in theory. Namecoin may have some trouble following this in practice since our SPV client is in Java, which has an extremely long lookup time for the first few lookups after boot due to the JIT warmup. This doesn't reveal *which* names were previously looked up (at least, I doubt it would), but I can imagine fingerprinting attacks that detect a Namecoin client that hasn't done many lookups since it was last rebooted. Not clear to me how much damage this can do in practice, but caution is warranted in the absence of evidence. Maybe looking up a few junk names immediately after initial boot would be sufficient to fix this.

We should probably add a security notes section for how to write plugins that aren't dangerous: a bad plugin potentially breaks user anonymity.

Strongly agree. Even though I'm reasonably familiar with Tor and anonymity software, I would definitely benefit from security notes to make sure I'm not doing something stupid. Everyone makes mistakes when working with codebases they're not familiar with, and documentation can reduce the risk of producing dangerous code. 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----- iQIcBAEBCgAGBQJY5V3EAAoJELPy0WV4bWVw8MMP/RLW+dD+S4JFDiskpmVPxZWW QAhDtwR7BoC82pt0xAISwJvGokw4o4Fps9P9t0UVKZ1MxB79z1GbYIQ0Q7B4MGtN nSaCUi0btGSK2JQ/2QvpB16pM+UUbJSMhc45kwq4/Zq/3irNQKS2XR3x2TdNH4VN hHdpDREBWGLLQ4iKSfISA45nNOgNgNVPcSBTkiTN1MPPUwck3J10ATn0auHISFpY jtsqiuC4pu+vOyUe/5xCYGrxd+UGTRuMXZi7yUGt822MZjtFNLFGW5VYZ5rT233Q qjsDvaku3I0ueMWIXBTfT2mU3iSY7Kq72iHBxdXOTy/2ecSvnyyo49k4r8UZuoZb c83eIP5v1LbYjte9o6OPaS+dLeJ9kI1cgEmE5O6wmbNUmAs8X7z6+fmYDMB403FM rVywQtng1qOv9TtFJxgiV+ATs9uA8p53wC9zimSD7qEJKDJW9Fsilcv92bc7RjSD 0VLeabaj+LoSnc8n5jXLrGPOxgtDE+p/iwu7RT2iQJ225XbguUrShxdQBjqvFuqv vCFHrvrwJnyR1bvk963V6fXKeZLxLZ18mX++q05fv4BGmldTSTgQjTkhpEB40GpL T+fjWFjc4FM3dY4sjzj7UQyWxtzAJkl6Gln8F9+HuXiaaGScw85F6OCRUFtkbpOy Fx0azrRJwHMKPdo3b9fL =3p7s -----END PGP SIGNATURE-----