On Tue, Aug 11, 2015 at 8:22 PM, Alec Muffett <alecm@xxxxxx> 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: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: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: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 MuffettSecurity InfrastructureFacebook EngineeringLondon