Re: Last Call: <draft-ietf-dnsop-onion-tld-00.txt> (The .onion Special-U

Hi Ted,

> On Aug 11, 2015, at 5:17 PM, Ted Hardie <ted(_dot_)ietf(_at_)gmail(_dot_)com> 
> 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:

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.

...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:aem%aber@ukacrl.bitnet <mailto:aber@ukacrl.bitnet> - in 1991)

—
Alec Muffett
Security Infrastructure
Facebook Engineering
London

signature.asc
Description: Message signed with OpenPGP using GPGMail