On Sat, 8 Apr 2017 08:47:51 +0100
Alec Muffett <alec.muffett@xxxxxxxxx> 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.
Attachment:
pgp7pwp3_m0eG.pgp
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev