Re: [tor-bugs] #24774 [Core Tor/Tor]: Edit prop279 to support alternative name representations and non-English languages

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#24774: Edit prop279 to support alternative name representations and non-English
languages
------------------------------------------------+--------------------------
 Reporter:  nullius                             |          Owner:  (none)
     Type:  enhancement                         |         Status:
                                                |  needs_revision
 Priority:  Medium                              |      Milestone:  Tor:
                                                |  0.3.3.x-final
Component:  Core Tor/Tor                        |        Version:
 Severity:  Normal                              |     Resolution:
 Keywords:  prop279, review-group-28, tor-spec  |  Actual Points:
Parent ID:  #10747                              |         Points:
 Reviewer:                                      |        Sponsor:
------------------------------------------------+--------------------------

Comment (by nullius):

 Replying to [comment:5 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 [https://lists.linuxfoundation.org/pipermail/bitcoin-
 dev/2018-January/015537.html 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.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/24774#comment:6>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online

_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs