Opened 18 months ago

Last modified 14 months ago

#24774 needs_revision enhancement

Edit prop279 to support alternative name representations and non-English languages

Reported by: nullius Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: prop279, tor-spec, review-group-29, 034-triage-20180328, 034-removed-20180328
Cc: Actual Points:
Parent ID: #10747 Points:
Reviewer: Sponsor:

Description

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.

Child Tickets

Attachments (1)

279-naming-layer-api.txt.patch (7.4 KB) - added by nullius 18 months ago.
Patch on 279-naming-layer-api.txt (13cbcbc..3ad5b94)

Download all attachments as: .zip

Change History (12)

Changed 18 months ago by nullius

Patch on 279-naming-layer-api.txt (13cbcbc..3ad5b94)

comment:1 Changed 18 months ago by yawning

Add UTF-8 support, so as not restrict the Name System API to users of American English.

If people want that sort of thing, they can use RFC 3492 like everything else on the planet.

comment:2 Changed 18 months ago by nickm

Milestone: Tor: 0.3.3.x-final
Status: newneeds_review

comment:3 Changed 18 months ago by nickm

Keywords: review-group-28 added

comment:4 Changed 17 months ago by dgoulet

Component: Core TorCore Tor/Tor
Keywords: tor-spec added

comment:5 Changed 17 months ago by nickm

Status: needs_reviewneeds_revision

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

comment:6 in reply to:  5 Changed 17 months ago by nullius

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.

comment:7 Changed 17 months ago by nickm

Keywords: review-group-29 added; review-group-28 removed

comment:8 Changed 17 months ago by dgoulet

Milestone: Tor: 0.3.3.x-finalTor: 0.3.4.x-final

comment:9 Changed 15 months ago by nickm

Keywords: 034-triage-20180328 added

comment:10 Changed 15 months ago by nickm

Keywords: 034-removed-20180328 added

Per our triage process, these tickets are pending removal from 0.3.4.

comment:11 Changed 14 months ago by nickm

Milestone: Tor: 0.3.4.x-finalTor: unspecified

These needs_revision, tickets, tagged with 034-removed-*, are no longer in-scope for 0.3.4. We can reconsider any of them, if somebody does the necessary revision.

Note: See TracTickets for help on using tickets.