[tor-dev] Comments on proposal 279 (Name API)

[Jeremy Rand]

-----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 at 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 at 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-----