ietf
[Top] [All Lists]

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

2015-08-12 12:09:34
Hi again, Ted!

On Tue, Aug 11, 2015 at 8:22 PM, Alec Muffett <alecm(_at_)fb(_dot_)com> 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



Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail