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

[Yawning Angel]

On Sat, 8 Apr 2017 08:47:51 +0100
Alec Muffett <alec.muffett at gmail.com> wrote: 
> However: on this conference call it was made abundantly clear to all
> present - one could almost hear fingers being wagged - that it would
> be a bad thing for Onion addresses to (1) contain anything other than
> alphanumerics and non-leading-hyphens, (2) collide with IDNs and
> PunyCode.
> 
> Now: I flatly do not know where this is documented; it may possibly
> be some intersection of DNS and HTTP RFCs, and if we want to take the
> approach that "everything should be permitted unless it is explicitly
> forbidden!" then yes we should go chase those documents down so that
> we have rationales for our self-imposed bondage.

Ironically, I struggled with this a bit when I pushed for making tor
clients reject "obviously malformed" destinations right when they hit
the SOCKS server.

From what I remember/can tell, RFC 1912 has the rules on what a valid
`hostname` is, RFC 2181 suggests that DNS server implementations should
not enforce restrictions on what a valid `hostname` is, and from
experience enforcing strict RFC 1912 on the real internet breaks
`nytimes.com`.

RFC 6125 mandates "LDH Lables" (RFC 5890), but is only applicable to
TLS.

> However if we want to seek the path of least resistance and effort,
> the answer is obvious to any seasoned network administrator:
> 
> * alphanumeric
> * (whatever DNS label length)
> * (whatever DNS overall length)
> * single, and only single, dots at label separators
> * single, and only single, hyphens as spacers
> * (i'm trying to think if there are any more obvious constraints, but
> can't)
> 
> ...which will traipse merrily through any system one cares to name.

tor currently enforces most of those (label length is notably not
checked), and also allows:

 * `_` because `core3_euw1.fabrik.nytimes.com` despite what the RFCs
   say.

 * Trailing `.` used sometimes to make it explicit that the domain is
   absolute.

See: https://gitweb.torproject.org/tor.git/tree/src/common/util.c#n1080

> That's a lovely idea; one more to add to the mix is the process
> documented at:
> 
> https://github.com/alecmuffett/the-onion-diaries/blob/master/basic-production-onion-server.md
> 
> ...of hijacking addresses out of the DHCP network space and using
> them to configure interfaces with genuine, resolvable Onion names.
> It makes SSH and Apache configuration really clear when you can use
> the genuine onion address in configuration ("Listen") directives, etc.
> 
> But then that's /etc/hosts - that's *not* what goes to a Certificate
> authority to be signed, and it's the latter that the committees get
> exercised about.

Sure.

> Hyphenation, readability studies, boutique & frou-frou name schemes
> invented at the Tech University of Mercedes-Benz, and other shooting
> ourselves in the foot can, and should, come later. :-)

I'd be ok with, and would likely even advocate for "If you want your
naming system to be shipped with Tor Browser, it should follow certain
guidelines, including mandatory syntax, a label registry, and etc",
which is a matter of policy.

But that to me is orthogonal to "there should be a flexible way to
offload name resolution" (a matter of implementation).

In practical terms the tor code would need modifications to allow
anything super exotic anyway, and I doubt anything will actually get
shipped with Tor Browser[0] till long after prop 224 is fully
implemented.

Regards,

-- 
Yawning Angel

[0]: As much as I hate the fact that port 80 and 443 are basically the
only things that matter, that's basically the situation.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20170408/c44419cf/attachment.sig>