Hi there,
On Mon, May 11, 2015 at 06:15:47PM -0300, hellekin wrote:
> draft-appelbaum-dnsop-onion-tld-01 came as way to fast-track the
> processing of .onion special-use TLD, as the P2PNames draft was
> considered too controversial (and maybe too complicated?).
As one of the people who has objected to the p2pnames draft, I would
say that appelbaum-dnsop-onion is an attempt to break out one of the
candidate special names from the others, so that all the applications
don't share fate.
> A simple comparison of the IANA Considerations for the P2PNames and the
> OnionTLD drafts highlights critical flaws in the OnionTLD draft that
> curiously didn't receive any attention at all so far (except my own, but
> I reserved my comments up until now for others to come up with this, in
> vain.)
Well, they're different drafts, and therefore it's not completely
surprising that they don't agree. I suspect part of the issue here is
that appelbaum-dnsop-onion has been adjusted because of some comments
some of us made.
> 1. the users considerations pretend that users must use onion-aware
> software in order to access Onionspace, but I assert that you and I can
> use an ordinary Web browser, type in a .onion address, and access the
> requested service. Not only OnionTLD conflicts with P2PNames on that
> point, it also confuses users' awareness and application software
> responsibility (and possibly the scope of IANA Considerations' first
> question).
I've asked about this issue several times, and I keep getting
different answers. What isn't clear to me is whether there is
somewhere in the user's stack -- maybe it's the resolver, maybe it's
the application, whatever -- that knows that onion is special and
therefore shouldn't be looked up in the public DNS. I assume there
has to be _somewhere_ that is special, or the alternative resolution
obviously wouldn't work. I think that needs to be indicated
somewhere, because this fact is what makes onion a candidate under
6761, I think.
> 2. more importantly, where P2PNames imposes NXDOMAIN response to
> authoritative name servers, OnionTLD makes it a soft requirement, thus
> leaving the possibility for name servers to hijack Onionspace without
> user consent nor awareness.
Yes. That is in fact a possibility. There is no way for a protocol
document to make it impossible for someone to redirect this name, and
if your queries for onion leak into the public DNS you have to be
prepared for the possibility that someone will provide a local answer.
It's a plain fact of working on the Internet, and trying to legislate
this in a protocol document provides inoperative assurances. In fact,
the way that onion was deployed without a registration with the policy
authority over the root zone rather nicely illustrates this fact about
the DNS: the global DNS only works because everyone uses the same
root. If people start fraying that use, then the DNS itself is in
trouble.
> 3. this error is confirmed for DNS server operators, where OnionTLD
> makes it a soft requirement not to override responses.
But again, you simply can't legislate that. People do this all the
time. Indeed, some people pay for services in which the answers from
their resolvers are munged to prevent access to "bad" sites and so on.
You could make this sort of fiddling with the data possible to detect
using something like DNSSEC, but you can't make it impossible to do.
> That the P2PNames draft remains controversial should not remove from its
> qualities, and notably its technical fitness and attention to detail.
Issues 2 and 3 were problems with the p2pnames draft when it first
surfaced, and I believe I included them in the comments I sent on it
in the first place. If I didn't I apologise.
> The OnionTLD interpretation is wrong. I want for proof that I can
> browse Onionspace with an ordinary Web browser that does not treat
> .onion sites any differently from a .org or a .net.
Well, surely _this_ isn't what you want, because if that were the case
then the onion TLD would fail to resolve at all, since it isn't
delegated.
> OnionTLD contradicts this: "Users: human users are expected to recognize
> .onion names as having different security properties, and also being
> only available through software that is aware of onion addresses."
But the point is, you need to know whether you have an onion-aware
resolution path available, or else you will leak your queries to the
public DNS. I think that's all it says.
> OnionTLD says: "Application Software: Applications that implement the
> Tor protocol MUST recognize .onion names as special by either accessing
> them directly, or using a proxy (e.g., SOCKS [RFC1928]) to do so.
> Applications that do not implement the Tor protocol SHOULD generate an
> error upon the use of .onion, and SHOULD NOT perform a DNS lookup."
What's the problem with this? Isn't this what you want, that the
onion queries don't leak?
>
> *
> In P2PNames, "immediate negative responses" is not specified yet (for
> lack of discussion about it across domain names) as negative responses
> might be different than NXDOMAIN in some case (e.g. for .gnu domains).
> *
Yes, that difference is precisely why some of us have claimed that
p2pnames can't go ahead as written, because the considerations are not
identical for every name. Asking for "negative responses" gets us
back into the kind of imprecision that has vexed the DNS for years.
What kind of negative response do you want for each case?
> *
> This is the main conflicting point: OnionTLD does not recognize .onion
> as special and allows Authoritative DNS servers to respond for .onion
> ("SHOULD").
"SHOULD" doesn't mean, "This would be a nice idea." It means, "You
better do this, or have a pretty good reason why you don't." One
possible local reason could be that a local authoritative server (or
rather more likely, resolver) is overloading onion -- for instance, to
catch queries that were going to the DNS that shouldn't be. It's
certainly going to be necessary to have some authoritative servers
respond to onion queries if we hope to sink that traffic AS112 style.
And I presume that, as onion's popularity increases, we'll need to do
that.
> Until now the debate has been in opposition to a single P2PNames draft
> covering more than one domain, and this argument mostly suspended actual
> criticism of the contents of the draft itself.
I seem to recall writing quite a long series of comments about
p2pnames a long time ago. I didn't send additional comments when the
document didn't get broken up, becuase I said in the first place that
I thought it was a fatal flaw.
> I'm looking forward to break this opportunistic behavior to play
> politics and satisfy administrative formalities
I think that's just an _ad hominem_ argument. There are good reasons
for the changes in appelbaum-dnsop-onion as compared to p2pnames, as
outlined above.
Best regards,
A
--
Andrew Sullivan
a...@anvilwalrusden.com
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
