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 09:58:12
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.



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
.txt

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.


Software is pretty good at ignoring what it cannot deal with nowadays.


​Where the coding effort has seen this species of failure before,
generally yes.  Novel failures require work to resolve.​



​So, RFC 6761 says this:

    Similarly, if a domain name has special properties that affect the
   way hardware and software implementations handle the name, that apply
   universally regardless of what network the implementation may be
   connected to, then that domain name may be a candidate for having the
   IETF declare it to be a Special-Use Domain Name and specify what
   special treatment implementations should give to that name.

​

​It is abundantly clear that software implementations handling .onion
addresses should behave differently from those handling standard DNS
registrations.  But it is not currently within the IETF's ability to
specify the special treatment in this case.  Note that I don't mean here
specify "how TOR itself works", but to specify how this works when these
names appear inside other contexts.


So, for my clarity, your concern is one of these two contexts:

(a) the bigger non-tor-enabled universe and how it behaves when
encountering a perhaps-longer-than-expected label as part of the “Host”
element of a URI?

Or perhaps...

(b) How the tor-enabled universe with its non-IETF-defined features will
make use of IETF URI schemes (eg: mailto:) and yet one day may start
using them in non-standard ways/creating non-standard URIs?


​B is closer, but "What constraints on the operation of Internet protocols
and systems arise from the need to have protocol identifiers from these two
different systems interoperate when the switch for distinguishing among
them is embedded in the identifier?".  Using a pseudo-tld to indicate
namespace operation was not contemplated for a lot of the deployed systems
and protocols. Bits of it will work and bits of it will not when presented
with them.  You may not care about the bits that will not, but
interoperability is the IETF's core concern, and that includes things
leaking from local namespaces into the global ones.  I'm sure the DNSOP
folks have made the impact of those on their part of the universe
abundantly clear, but it may extend far beyond that.




Imagine for a moment that I run a service that delivers mail via TOR.
While RFC 5321 does not contemplate .onion addresses, it does note that MX
records may be resolvable with either v4 or v6.  What would actually break
if someone put a .onion address in the MX record of a domain?


Well, strictly, I feel that if one can insert an MX record for a “special
use” domain which IANA will not delegate (see earlier thread regarding IANA
feedback for this draft) then perhaps there is a bigger issue at hand, viz:
the ability to insert long junk records of any kind into an MX record -
which would not be an issue caused by this draft.

​Someone seeing a mailto: with .onion might well assume that this was a
reasonable thing to do, where there is no known incentive to insert junk
now, so I believe your response misses the point.​


To answer your question literally, I believe the answer would be someone
receiving SMTP code 553 “You are attempting to send email to a domain that
is not recognized by this server”.

​The error seems more likely to me to be a resolution error/

What would break if a later version onion address ceased to follow DNS
syntax for labels below .onion itself?

That’s a good question that seems to assume (lack of) good faith of the
Tor community to want to interoperate with the internet as a whole; given
the actual challenge at hand - which I can sketch as “the tor onion
community are trying to use the HTTP/S schemes in URIs” - it seems pretty
plausible that transparent interoperability is actually their goal, though
of course I can’t speak for all Tor users everywhere.


​Would the Tor community commit to making sure future onion identifiers
follow the DNS label length and IDN restrictions?  That would help​ a lot.

Some of them may want to innovate, perhaps (in wild, nostalgic,
hypothetical speculation) we will see a renaissance of UUCP bangpaths over
some Onion-aware e-mailer; wouldn’t that be exciting and innovative?


Building a DHT out of onion nodes and routing SIP across it with p2psip?
Sure, go to town.​



But I wouldn’t want to pre-emptively squelch such an innovation for fear
of how Outlook would cope if and when it encountered something like:

mailto:…!mcsun!ukc!aber!aem (this was one of my e-mail addresses in 1991)

…because Outlook would not be the target audience for such a feature.

I believe that one of the underlying principles of HTML is that “if you
don’t understand something, ignore it”, and this behaviour (ignoring this
bangpath scheme) seems okay to me. Or punting it.  Whichever.


The answer to question 1 and question 2 may be very, very different.

As I said in a previous thread, I think the IETF didn't do a good job in
setting up this registry, and I think we're actually talking about two very
different things.  One is "special use DNS names" and the other is "names
in other namespaces than the DNS".  I think the first one we have our hands
around.  There's a huge potential range in that second category, but the
more a namespace outside of the DNS tries to share contexts with the DNS
(like URL contexts), the messier it is going to get.  Honestly, I worry
folks will assume from seeing a namespace in one DNS-like context that it
can go into others, and that it will break more than that namespace.


To me this provides all the more reason, in this popular, million-plus
user special case, to put it on a proper footing as a special name, adopt
IANA’s suggestion of not delegating it but annotating its special nature
clearly so that CA/B-Forum will bless SSL certificates for it, and through
awareness learn how to find a middle ground that is acceptable to all.

I am sympathetic. I have lived in a world of dual namespaces.  Another of
my old e-mail addresses was:

aem%uk(_dot_)ac(_dot_)aber(_at_)nsfnet-relay(_dot_)ac(_dot_)uk

For those who don’t recall, the UK academic network was once X.25 not
TCP/IP, and had an addressing scheme which ran right to left; and it was a
good day when the UK JANET network finally dumped bigendianism and all
hostnames (for good or ill) ran from left to right.

BUT: again, to reiterate:

1) Onion address spaces are currently utterly DNS “compliant”, except for
having a currently unofficial rightmost label.

​I think you mean they follow the DNS label constraints, right?​



...and...

2) All forward-looking statements about them are speculation, but
practically the most likely thing to happen to them is that they will get
longer.


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.



Holding up the registration of .onion does not help that, of course, but I
hope it helps you understand why we are looking for more detail than "this
external pointer to a changeable specification should be enough.”


Concern for standardisation is important and good; so is general adherence
to standards, especially in spirit.

I hope that neither is ever constructed by IETF in order to proactively
brake innovation or change, especially where good faith is evident.


​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,

regards,

Ted




    - alec (mailto:aem%aber@ukacrl.bitnet - in 1991)

—
Alec Muffett
Security Infrastructure
Facebook Engineering
London