Re: Last Call: <draft-ietf-dnsop-onion-tld-00.txt> (The .onion Special-Use Domain Name) to Proposed Standard

[Alec Muffett <[e-mail]>]

Hi again, Ted!

> On Tue, Aug 11, 2015 at 8:22 PM, Alec Muffett <[e-mail]> wrote:
> 
> Given the “special” - as in “special name” - nature of Tor, it seems likely that all intentional use of it will be "opt-in" by via software that is capable of dealing with its addressing scheme and any URIs associated with it.
> 
> ​This is where we have an apparently philosophical ​difference, and, where, I think the failure of the registry document is most evident.  I believe that the category of software that will have to deal with this special use name is much broader than the opt-in Tor software, and I think that's what's contemplated in the paragraph I quoted above ("that apply universally regardless of what network the implementation may be connected to").  If Tor operated in a vacuum, it would not need this registration; it does not, and does.


Tor Onion Addressing does not operate in a vacuum - you are quite correct - it seeks to use properly TCP-like circuits, HTML, CMS, HTTP, and now HTTPS; the latter is perhaps the first technology where the technology has become (to some extent) hard-coded to the presumptions of Internet communication, in that SSL certificates are required, the authorities for those certificates have been issuing them against DNS names; but now, through CA/B-Forum’s Ballot 144:

https://cabforum.org/2015/02/18/ballot-144-validation-rules-dot-onion-names/

…CA/B-Forum are permitting CAs to issue certificates against “.onion” addresses.  For this to continue requires a step-up to IETF that “.onion” be reserved as a global namespace, upon which DNS need not tread. This is an achievable situation.

In the spirit of “good fences make good neighbours”, one of the most important aspects of interoperability is one of boundaries, and registration of “.onion” in the way proposed will clearly define the boundaries between DNS and an extant network of users which is not dependent upon DNS and which will not go away, but might be worked with-and-around.


> Equally, any software not capable of dealing it, which stumbles across a “long” label or somesuch, should treat it as much as it should properly treat (ignore?) any URI which it is incapable of dealing with. e.g.: the fact that I insert a link such as the following in this e-mail, should not crash your browser:
> 
> http://a234567890123456789012345678901234567890123456789012345678901234567890.onion/hello
> 
> If you are still reading this e-mail, your browser or mailer survived that illegally-long-yet-parsable label.
> 
> ​
> It did, but truncated what it thought was a URI, so ​it represents a failure.


…and I will bet that if you had clicked on it, and if it hadn’t been “truncated”, you would next have an issue that you would not have received any data because you are not using Tor.  That would be because you were not using Tor software.

Under such circumstances that would be an acceptable failure, I think.

See the annotation cited in this blogpost for a similar example:

https://www.facebook.com/notes/protect-the-graph/making-connections-to-facebook-more-secure/1526085754298237

[…phiilosophical deletia…]



>> Regarding label length, I find it really interesting to note that the Tor draft discussion document for future onion addresses / hidden services cites examples thusly:
>> 
>> https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.txt
>>>    And a new name following this specification might look like:
>>>         a1uik0w1gmfq3i5ievxdm9ceu27e88g6o7pe0rffdw9jmntwkdsd.onion
>> 
>> …where the longest label is *53* characters long, still well within the bounds of DNS legality (63) and yet leaving 10 characters grace for padding hyphens, or something. But for some reason we are still arguing about future speculation and what “might” happen.  Honestly, I wonder why *that* is?
>> 
> 
> ​Because the registry assumed that the IETF had change control for special use names that involved non-DNS​ resolutions.   Clearly it does not for .onion, so we are working out what to do in real time, rather than simply following a well trodden path.
[...]

> ​Good faith don't grow Christmas trees, in the words of my grandfather.  My frank assessment is that if the Tor community can commit in good faith to follow the DNS constraints for its identifiers (don't step on IDN rules, follow the length guidelines, etc.), the ​IETF should register .onion and then immediately close the registry for repairs and refactoring.
> 
> But that's just my own opinion,


Your grandfather spoke wise words.  Nick Mathewson is the engineer who leads Tor development on Onion services.  He writes thusly on this matter:

https://lists.torproject.org/pipermail/tor-dev/2015-August/009275.html

How will that fly with you?

    -a