[tor-dev] Comments on proposal 279 (Name API)
yawning at schwanenlied.me
Sat Apr 8 09:57:21 UTC 2017
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
> 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
RFC 6125 mandates "LDH Lables" (RFC 5890), but is only applicable to
> 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
> ...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
* Trailing `.` used sometimes to make it explicit that the domain is
> That's a lovely idea; one more to add to the mix is the process
> documented at:
> ...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.
> 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 till long after prop 224 is fully
: 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
Size: 833 bytes
Desc: OpenPGP digital signature
More information about the tor-dev