On Sat, 8 Apr 2017 08:47:51 +0100 Alec Muffett alec.muffett@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-productio...
...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,