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

On 8 April 2017 at 03:23, Yawning Angel <yawning@xxxxxxxxxxxxxxx> wrote:

On Fri, 7 Apr 2017 11:44:03 +0100
Alec Muffett <alec.muffett@xxxxxxxxx> wrote:
> If I was in charge, I would say that we risk overthinking this, and it
> would be better to:
>
> - mandate use of fully DNS-compliant syntax, including but not
> limited to: acceptable max length, max label length, charset and
> composition

Fully DNS-compliant only limits max length and max label length, unless
there's something that supersedes RFC 2181.

You have an excellent point, and I remember fondly the happy days at Sun's Network Security Group when I would set the name of my workstation to "#" in DNS and use it to break into people's machines because ".rhosts" did not support comment characters in the way that people expected.

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.

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.

I am purposely leaving specific "label" and "overall" lengths out of this list because although the correct figures are googleable, they tend to trigger citation wars and off-by-one arguments so it's safer to discuss them symbolically.

I intentionally left a lot of this unspecified because one of the use
cases I envisioned was an "/etc/hosts" analog that lets users easily:

* Stick all their hidden services under their own name hierarchy.

eg: git.yawning -> <long public key>.onion

(...elided...)

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.

Onion addresses are not really hostnames, they're a machine-readable number a-la IPv4 and IPv6, which - by amazing, fantastic fortitude - happen to be exactly compliant with DNS which means that subdomains "work" where they protocol passes them along in (eg: "Host:" header) metadata.

The Elders of the Internet (TM) did not have the wisdom to see that "www.127.0.0.1" would be a useful thing; they put everything into tidy buckets - layer 3 goes here, directory lookup goes there - and at the outset broke decentralisation and imposed hierarchy by means of user expectation.

Whomever the clever person was who unbroke it by making tordaemon ignore "subdomains" should be honoured - they (accidentally?) re-merged the two namespaces and - so long as Tor walks the knife-edge of being compliant in both namespaces - then Onion addressing is in an amazing position:

* all the browser technologies which assume DNS can work without modification

* this includes availability of HTTPS certificates

* and therefore all future web technologies like WebRTC

* but the addresses are end-to-end and self-created, thus obviating the whip-hand of DNS censorship

* and onion services are effectively "published" (X.25 did similar) reducing attack surfaces without firewalls / intermediation

* intermediation which Tor bypasses anyway, because NAT-punching / Rendezvous, etc.

It's hard to express how amazing this situation is; it's really like winding the clock back to the 1980s and getting a whole new network architecture, for free, which supports all the modern bells and whistles, all because of the Host header, SSL-compliance and fake onion subdomains.

This is why it's essential to get this right. :-)

Yawning wrote a bunch of stuff here, but I am gonna elide it and sent this message to see if it changes anything, and then revisit.

I'll just finish by saying that I am very excited about:

www.somethingexceefinglylonggoeshereandwearenotreallysureaboutformat.onion

...because we can complain about usability, but this ^- is the first step on the moon. This is the awesome thing.

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. :-)

-a

http://dropsafe.crypticide.com/aboutalecm