On Tue, Aug 11, 2015 at 3:59 PM, Alec Muffett <alecm(_at_)fb(_dot_)com> 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."
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 Muffett
Security Infrastructure
Facebook Engineering
London