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