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

[Alec Muffett]

On 8 April 2017 at 03:23, Yawning Angel <yawning at schwanenlied.me> wrote:

> On Fri, 7 Apr 2017 11:44:03 +0100
> Alec Muffett <alec.muffett at gmail.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20170408/2b245118/attachment.html>