Re: [DNSOP] More complete review of draft-grothoff-iesg-special-use-p2p-names-01

[Andrew Sullivan <[e-mail]>]

On Tue, Dec 31, 2013 at 09:06:38PM +0100, Christian Grothoff wrote:
> 
> What kind of metric do you propose, and how do you propose to acquire it?

>From what you're saying about the different cases, it sounds like
different metrics are going to be relevant.  For instance, it seems
you could just count for .bit, but presumably the Tor examples could
be worked out from rough estimates of the size of the Tor network.  

> And again, a key question for me is, if you really want to _encourage_
> people to _first_ deploy at large scale and _then_ reserve the name.

No, I don't.  What has happened here is, frankly, that the namespace
was squatted on, and you're trying to normalize.  I think that's
valuable and I want to support it.  But what would have been _better_
is to have a discussion early when the names were being built into
protocols.  How to do that is also a problem, but maybe if we can make
it relatively painless in this case it will be more obvious that it
could be less hard in future when it's needed.

> For me, label-squatting implies that someone sits on a label and makes
> no use of it

I don't mean it that way.  This is "squatting" in the traditional
sense of taking up residency without really having the right to do so.
What's happened, according to your draft, is that these different
names are being used _as though_ they're DNS names, but they're
actually not DNS names.  The point of the draft is to say, "These
names are going to show up in DNS queries.  They shouldn't, but they
will, so to be safe please set these names aside."

Look at it another way.  Suppose that GNS names had a completely
different form.  Say, for example, that GNS had modelled its name
syntax on the old UUCP addresses, but used a different separator.  So,
just say, gnu&bob&alice, to get to Bob's friend Alice.  If that ever
somehow went into the DNS resolution system, it'd fail immediately,
always, from the root.  That wouldn't be great for the root, but at
least we wouldn't have a parallel namespace that looks just like DNS,
but isn't.

> so a better question might be if there should be a process
> to "unreserve" names should they fall into disuse.

How would you know?  If you can't count users of .gnu now (don't even
know what "users" means, indeed), how would you know when it was safe?

> > _Many_ of the references seem to be works in progress or unstable web
> > pages.  That needs to be fixed for this document to be a useful
> > specification.
> 
> I was told that i2p2.de recently moved to geti2p.net.  Which other
> pages are unstable in your experience? ("Worked for me...").

Oh, sorry.  I meant the other "stable": normally, we want the
references in documents (and require the normative references) to be
"stable references" in the sense that the target can't change.  So a
URI isn't enough -- we need a permanent reference to a versioned
document.  (This is the reason RFCs can't be changed once they're
published.  They're an archival series.  If you want to "update" an
RFC, you replace it with a new one.)

 
> >     […] Note that ".gnu"
> >    names SHOULD follow the naming conventions of DNS.
> > 
> > What does this mean exactly? 
> 
> > Is this the LDH rule?
> 
> Yes, in the sense of "SHOULD".

Ok.  This is probably the right interpretation of the STD 13
"preferred syntax" (== LDH rule).  What STD 13 says, in effect, is
that you can put anything in there, but things will tend to work
better if you follow LDH.  (Note that RFC 1123 actually relaxed the
rule, because originally labels couldn't start with a number either.)

What is the reason for continuing this tradition in GNS?  (That's
probably out of scope for this document and even this draft, but the
LDH rule has been a PITA and it's one of the things that would be nice
to ditch if we could.)

> > Is GNS subject to IDNA?
> 
> Yes.

Wow.  Are you sure you want to buy that much pain?

> > Or are labels just bags
> > of octets?  
> 
> No.

Why not?  If the LDH rule is only SHOULD, then what do you do with
octets outside that range?  

> > Are they only 63 octets each, with a maximum 255 limit?
> 
> Yes, in the sense of "SHOULD". However, if the DNS protocol is not
> used ("pure" GNS resolution with GNS-enabled applications where
> a DNS packet is never created) is is theoretically permitted for
> an application to not enforce these constraints.

This advice is worth what you're paying for it :) but I think that's
going to hurt you in the long run.  You're going to get
interoperability problems between people who actually enforce 63/255
and people who don't.  Again, out of scope for this.

> > left out completely because it's well-specified somewhere else.
> 
> I can live with leaving it out. Any objections to that suggestion?

None here.

> Well, it doesn't really make sense to cascade '.exit' targets like
> that, as an exit is prohibited from re-entering Tor (for security
> reasons).

Of course not.  I think the collective experience of DNS operators,
however, allows us to suggest that if there is something nonsensical
that is legal under the protocol, someone will start doing it.  In my
day job, in fact, I sometimes meet people relying on those nonsensical
things.  So I thought it might be worth calling out.

>  Also, yes, in theory appending
> "f97f3b153fed6604230cd497a3d1e9815b007637.exit"
> even once can cause one to run over the 255 limit on DNS names,
> in which case the answer is "tough luck, won't work".

Ok.  It would be good to note that.

For the whole issue, then, I'd suggest something along these lines:

    Because every name ending in .exit is at least possibly a valid
    hostname in itself, it should be noted that it is theoretically
    possible for those names to be picked up and used in the construction
    of .exit names again.  There is no reason to do this, but it is
    possible.  In constructing such a name, it is possible to exceed
    the total length limit for DNS names.  Such names may fail or
    behave unpredictably when used with DNS resolvers.

> Well, let's say the person who designed this is no longer even
> available for discussion. We're documenting the facts, not
> necessarily what one might consider a well-reasoned design
> choice (in my opinion).

Ah.  I'd leave out the details about the way the design is supposed to
work, then, and perhaps point out that discussion of the details of
operation are beyond the scope of the document.

> Well, if I had a 4,000-entry /etc/hosts file shared with tens of
> thousands of other users, I think I would also try to put all of
> those entries under some special TLD to ensure everyone knew that
> I was using names from that list, as opposed to ordinary DNS names

Why?  My employer runs dyndns.org, among other names.  We have way
more than 4,000 names under there.  Why wouldn't that work just as
well in this case?

> Well, I always thought of Namecoin and bitcoin as money-burning
> activities, but feel free to invest in Namecoin then ;-). 

Snort.  I didn't say it'd make money _for me_!

> I agree with you that the _technical_ reasons for a TLD are likely
> the weakest for Namecoin, and I suspect the marketing/usability
> concerns were the dominating reason.  But again, we're documenting
> how it was deployed.

Yes.  But this is one of those joints between mere protocol and
policy, because some time ago ICANN became responsible for the policy
of root zone operation.  (The analogy with Apple is a good one -- the
deployment of .local was, frankly, a similar case of
namespace-squatting.)  Nobody cared about this before ICANN adopted an
in-principle indefinite expansion of the root zone, but now we have a
problem.

Getting evidence of the number of actual use (however we work that
out) will go a long way in the argument, though.  On the other hand,
suppose the registration doesn't happen.  The reason that .local (or,
probably more directly comparable in this case, .corp) should possibly
be on the special-use registration list is because we know that there
are services using those names and that there will be security and
user-confusion side effects if those names are also registered in the
DNS name.  Similar arguments for this case wouldn't hurt.

> This is again an interesting split in your logic:

I don't think so -- see the discussion at the beginning.  In particular,

> You suggest people to reserve pTLDs only once  they've reached
> a significant size

I don't think this is the case.

> 3) We decide to not even acknowledge the reality and pretend
>    that RFCs are all there is.

I agree that this is a stupid result.  (By way of evidence, I'm one of
the primary offenders behind DNS64, even though I think it's a Bad
Idea in general.)

> > security consideration of the document, but a consideration in case of
> > non-document :)
> 
> True. Are you arguing to remove this sentence?

Yeah, or just add a note to the RFC Editor saying to remove that bit
before publication.  

> An alternative might be to mention that information leakage via DNS
> servers that fail to return NXDOMAIN might be a security consideration
> that remains even if the draft is published.

I think _that_ would be useful, yes.

> > ajs@[gnu.org.f97f3b153fed6604230cd497a3d1e9815b007637.exit]?  I bet
> > not.  It's simply not true that names and numbers can everywhere be
> > used interchangeably.
> 
> I don't quite see why this would not work in principle, assuming your
> mail client is configured to route SMTP over Tor and the specified
> exit supports exiting on port 25 to gnu.org.

Because the [ ] notation signals that what's in there is an IP
address, not a name.

> I guess the question is what you define as "DNS resolver".  For example,
> is the "dns2gns" proxy --- which speaks DNS (to applications) and then
> forwards
> ".gnu" and ".zkey" to GNS and everything else to DNS --- a "DNS resolver"?

Only partly.  This is similar to the confusion we had about recursive
resolvers and caching name servers.  In the DNSSEC documents, you can
see discussion about "the resovler side of a recursive name server"
and "the name server side of a recursive name server" (or something
similar).  Your example is of a general-purpose resolver system that
does both DNS and GNS.  For the purposes of protocol, then, you have
something like (ASCII art, sorry):

    resolver ---->  DNS ---->  DNS resolver ---> DNS
     |----->  GNS --->  GNS resolver ---> GNS

For the purposes of implementation, these may well all be the same
code.  But for the purposes of the protocol, we need to distinguish
them.

> (browsers, wget, telnet, etc.) for GNS do not need to be modified at
> all, or for other pTLDs the modifications are limited to the addition
> or configuration of SOCKS support.

Ok, that is probably important to make clearer; probably the
each-name-gets-own-question-answers will do that.

> I think you're mis-reading the point here, as the Namecoin block chain
> is not obtained using the usual DNS protocol from some authority. So
> DNS server operators that wanted to do this would NOT go out to some
> IP address of a TLD operator that was granted ".bit" operation from
> ICANN to fetch the block chain; instead, they'd have to participate
> in the Namecoin network to observe block chain updates (a rather
> daunting process, so this "MAY" is one that I personally don't expect
> to see happening anytime soon by any major ISP).

This is an even worse idea.  What you're suggesting there is that
recursive name server operators should add the .bit name to the
answers they give out; but they don't get that answer from the DNS.
Quite apart from what happens in the presence of DNSSEC (I think it's
"fails completely"), I think it is in general bad advice to tell
people to populate their DNS caches with data from outside the DNS.

> I expect them to be handed around by end-users and within applications.
> I do not expect them to be handed around within UDP packets on port 53
> (with the exception of ".bit").

But they will be:

> I expect that this MAY happen, but if the draft is accepted, one
> of our goals is to explicitly authorize DNS operators to prevent
> this.

You can't "prevent it".  You can just have them swallowed somewhere
else in the DNS system.  They _will_ get passed around on port 53.
Therefore,

> > "resolved or did not".  But perhaps what you are saying is that these
> > ought to be added to the list in RFC 6303, and that they should always
> > answer NXDOMAIN?  I could certainly live with that.
> 
> Yes, exactly.  The formulation did end up a bit unclear and should
> be fixed.  Our intention was exactly to allow servers to immediately
> return NXDOMAIN without going to the root.

what I'd do is take a page out of RFC 6303, or follow the text in
question 4 in the RFC 6761 discussion of .test:

   4.  Caching DNS servers SHOULD recognize test names as special and
       SHOULD NOT, by default, attempt to look up NS records for them,
       or otherwise query authoritative DNS servers in an attempt to
       resolve test names.  Instead, caching DNS servers SHOULD, by
       default, generate immediate negative responses for all such
       queries. […]

> Again, thanks for your comments, we'll try to address those in the
> next iteration, many of these were really helpful.

Glad to be of help.  

Best regards (and happy 2014),

A

-- 
Andrew Sullivan
[e-mail]