Edit prop279 to support alternative name representations and non-English languages
Attached is a git diff patch with edits to torspec.git/proposals/279-naming-layer-api.txt (patch on 13cbcbc). Inspired by discussion on tor-dev:
https://lists.torproject.org/pipermail/tor-dev/2017-December/012743.html
https://lists.torproject.org/pipermail/tor-dev/2017-December/012746.html
Brief conceptual overview of the most significant changes:
-
Support Name System API plugins which transform self-contained alternative representations of the data in .onion names. These can be safely configured for a global wildcard '*', then sandboxed with neither network nor filesystem access.
-
Add UTF-8 support, so as not restrict the Name System API to users of American English.
-
Specify failure status codes which will cause name resolution attempts to stop, even if the name may match the TLD for other plugins at a lower priority. This is useful if a plugin configured for a '*' TLD definitively recognizes that a name is invalid, e.g. due to checksum failure.
-
Other changes which support the foregoing objectives.
Please review and commit.
Trac:
Username: nullius
Activity
changed milestone to %Tor: unspecified
Trac:
Username: nullius
+1 on using RFC3492 if we want unicode support.
As for the other changes:
- I like the idea of explicitly saying "This address is definitively non-mapped; no other plugin should be allowed to map it.
- I am unconvinced that we need a * wildcard; the motivating examples seems like something that could just as well be done within a separate domain.
- I'm not sure that the sandboxing section is necessary. We should say that all plugins should only access the network over Tor, unless they are using some comparably strong anonymity mechanism. And for filesystem access, if we do allow * wildcards, there's no reason to suppose that they don't need caching as much as anything else.
I think that having separate patches for the different issues here might make them easier to discuss.
Trac:
Status: needs_review to needs_revision-
Replying to nickm:
Thanks for the guidance, @nickm.
If you want for me to split out different patches, then when time permits (not now), I could edit everything into atomic commits in different branches and push it up somewhere under https://github.com/nym-zone . That would be less burdensome for me than trying to keep track of and upload multiple patch files. Per
doc/HACKING/GettingStarted.md, would that work best for you also?In response to some of the points you raised:
+1 on using RFC3492 if we want unicode support.
I am strongly against making this an absolute requirement. The SOCKS v5 protocol can pass any arbitrary octets, even names with embedded
'\0's. We probably want to forbid those and other control characters; but if a SOCKS request hands Tor a name which won’t garble the Name System API protocol, then Tor should be pass that on to the Name System API resolver as an opaque blob.Of course, currently existing applications will give Tor non-ASCII names in Punycode. Still, I urge that permitting this would help future-proof the spec for use with non-DNS-like names. Punycode is only a (horribly designed) backward compatibility layer to meet the needs of a vast installed base of DNS software which the Tor Name System API will never need to deal with.
Whereas as a potential implementer, I must say, Punycode decoding is a thing I’d prefer to avoid in security-sensitive code. A search of the CVE database tends to support me here.
I am unconvinced that we need a * wildcard; the motivating examples seems like something that could just as well be done within a separate domain.
At least as from me, the idea is to permit address encodings which don’t even look like RFC1034 Internet domains. I presented two different use cases on
tor-dev. There certainly must be other many use cases I haven’t thought of.I'm not sure that the sandboxing section is necessary. We should say that all plugins should only access the network over Tor, unless they are using some comparably strong anonymity mechanism. And for filesystem access, if we do allow * wildcards, there's no reason to suppose that they don't need caching as much as anything else.
My own use cases need neither network nor filesystem access; but I will try to edit my proposed change to allow for those which do, without being overly permissive in some way which may compromise security.
The proposal as written states under §3.2, specifically discussing
'*':Perhaps we trust the name plugin itself, but maybe the name system network could exploit this?
What does this mean? Is there any specific information on what potential exploits the spec authors have thought of? Would requiring Tor-only connections prevent these potential exploits? I should ask on
tor-dev.
As a general point: When designing a new spec for such a feature as the Name System API, I suggest that it’s important to not limit unforeseen potential use cases. Don’t even try to guess what future innovations will look like, other than thinking like an attacker and trying to break things. As long as security is not compromised, the spec should be as flexible as it reasonably can be.
This reminds me of a design philosophy I just yesterday saw well-expressed by Mark Friedenbach in a totally unrelated discussion:
Finally, even if we had perfect foresight into how a feature will be used, which we don't, it is still the case that we would want to enable permission-less innovation with the generic construct... [It] is the opinion of this author that new [] features should follow the UNIX philosophy as expressed by Peter Salus and Mike Gancarz and paraphrased by yours truly:
- Write features that do one thing and do it well.
- Write features to work together.
- Simple is beautiful.
“Permission-less innovation” means that if someone invents a .onion pet-name scheme which doesn’t look like DNS at all, then the Name System API should Just Work with it.
Trac:
Username: nullius moved to tpo/core/tor#24774 (closed)
