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

[Alec Muffett <[e-mail]>]

Hi Ted,

> On Aug 11, 2015, at 5:17 PM, Ted Hardie <[e-mail]> wrote:
> ​Actually, the point was made up-thread that if names below .onion change in their length, it is not clear how well software which is expecting a more usual DNS-style authority section for http URLs (or mailto URLs etc.) will work.

I can see the concern - for instance there is Mailpile, a MUA which implements an extension called “SMTorP” - shortcutting SMTP delivery using an end-to-end Onion connection between the MUAs of two people once it is established that both of them are running Mailpile.

I am not sure whether SMTorP is intended to make the Onion addresses “directly” available for mailto: URIs, but I want to note:

* Onion addresses at the moment are 16+”.onion” characters long, and derived URIs are of a legitimate DNS syntax by any measure
* There is plenty of speculation about how unspecified software may deal with them if/when they get longer
* The URI standard seems (as I wrote upstream) to be strict in capping the length of a URI at 255 chars
* ...and reads inconsistently regards the assumption of DNS as a name resolution service and whether that should be enforced.

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.

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 <http://a234567890123456789012345678901234567890123456789012345678901234567890.onion/hello>.txt

If you are still reading this e-mail, your browser or mailer survived that illegally-long-yet-parsable label.

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


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


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

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


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

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?

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:

[e-mail]

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.

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


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

    - alec (mailto:[e-mail] <mailto:[e-mail]> - in 1991)

—
Alec Muffett
Security Infrastructure
Facebook Engineering
London