On Tue, Aug 11, 2015 at 3:59 PM, Alec Muffett <alecm@xxxxxx> wrote:
The Tor protocol is controlled by Tor, and is apt to change; there is enough description there to explain how onion addresses are mechanically generated, but to tie the registration RFC to a specific implementation/version seemed unwise.
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. So while I agree that linking the registration to a particular version creates a problem, the ability to evaluate the registration goes down when it is not.
It is my reading that any protocol eligible for a registration in the "Special
Names" registry has to be an IETF Standards Track protocol - the grandfathered
entries in that very registry nonwithstanding. Any deliberations w.r.t. the
Tor protocol are missing from the above draft and the Last Call message.We are not seeking to register the protocol. We are seeking to register a namespace that the protocol uses.
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.
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? What would break if a later version onion address ceased to follow DNS syntax for labels below .onion itself? 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.
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."
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."
regards,
Ted Hardie
/no hats
The "Special Names" registry does not offer any means to convey any particular
behaviour, let alone differences between various reserved names. It is more
than brave to expect that non-supporting implementations would be able (or
willing) to follow the SHOULDs in the first quoted block.The advice received from IANA last night as part of the last call, suggests this:However, one reviewer added the following:"My comment would be there is nothing in the IANA considerations regarding how IANA manages the root zone, although immediately prior it says:"'DNS Registries/Registrars: Registrars MUST NOT register .onion names; all such requests MUST be denied.'"I believe 'register' in this context is not sufficiently clear. Perhaps 'delegate' is intended? For example, normally for a reserved name IANA would keep a record in the root zone database to acknowledge this, but this could appear to prohibit keeping a record for this purpose. Further, my understanding is part of the reason for this whole I-D is to all SSL certificate vendors (which are often DNS registries/registrars) to allow registration of SSL certificates for .onion names. I would say a plain reading of this may prohibit that. I would suggest there be an explicit additional category that makes it clear it expects service providers, such as trust providers, for to support .onion domains in such applications."…so this suggestion - which myself and Jacob Appelbaum (the authors) warmly wish to adopt - would lead to “.onion” being reserved and not delegated, but also clearly documented as a space in which SSL certificates are to be issued. I think that would aid the goals we’ve sought to describe in the draft.It remains to be specified how these "generated" responses would interact
with DNSSEC validation. Again, it is unclear how agnostic (as of today)
recursive resolvers would learn about the new name and apply specific behaviour to it.I think the IANA proposition would mean that DNSSEC would cease to be an issue, but perhaps you would like to suggest some alternative wording for us to consider?The draft does not explain why it asks for a "special name" at the top level.
Neither the draft nor the Last Call document or envision any coordination
with the responsible body as per the MoU RFC 2860.I believe that that was dealt with extensively in DNSOP. Mark?-a—Alec MuffettSecurity InfrastructureFacebook EngineeringLondon