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

[Andrew Sullivan <[e-mail]>]

Dear colleagues,

I made some remarks in the earlier discussion of
draft-grothoff-iesg-special-use-p2p-names-00.  In this message, I
attempt to review draft-grothoff-iesg-special-use-p2p-names-01
completely.  I hope these remarks are useful.

Overall
=======

I remain extremely concerned that this effort represents another step
along a deep and extremely confusing path of mixing the domain name
system and other name spaces.  I think the IETF needs to figure out
whether we're going to accept that, historically, we had multiple name
spaces but that now we're going to have one big one; or whether we're
going to continue pretending that every other name space doesn't end
up wandering into the DNS anyway.  (If there are additional
alternatives, I am unable to think of them.)  I think a pragmatic
answer is to accept that, given the number of places we expose domain
name slots, anything that uses a name is going to end up having to be
somehow compatible with domain name slots.  But I think that is a
wide-ranging discussion that almost certainly needs to be tackled
#separately from the consideration of this particular draft.

For the purposes of this draft, I think it would be extremely good if
the draft included a section actually documenting the deployment of
these top-level labels on systems in reasonable use on the Internet.
The mere existence of some software somewhere isn't enough.  There
needs to be some evidence of deployment, I think, because otherwise
this is just a case of label-squatting.  That is, if the justification
for normalizing these names is just that some software implemented
them somewhere, then that becomes a trivial mechanism by which people
can do an end-run around the ICANN TLD procedures.  Therefore, I think
for this case we need some evidence of significant existing deployment
of these names in order to meet the terms of the first paragraph of
section 4 of RFC 6761.  (So, this requires an expansion of a paragraph
in section 1 into at least a paragraph for each label.)

The RFC 6761 questions to be answered for each reservation are
answered in this draft in section 5.1, with the questions answered for
all of them.  I think this is a mistake, because I think the
properties of the different names are actually different.  It'd be
much better just to refer to the 6761 questions, and say "here are the
answers" in each case.  So, just for example. I think these are the
answers for the .gnu label:

    1.  Yes.  Users must install GNS to use names under .gnu.
  
    2.  Yes.  The application needs to be GNS-aware, or else the
    application environment must support GNS.

    3.  Yes.  GNS is a parallel name resolution system and a
    GNS-capable resolver will need to know how to resolve such names.
    A GNS-incapable DNS resolver will always receive RCODE=3 (Name
    Error) for any name beneath .gnu.

    4.  No.

    5.  No.

    6.  Yes.  The .gnu top-level label "shifts" the name space to GNS
    as opposed to DNS.  A DNS operator that attempts to configure the
    .gnu name space is therefore treading on the GNS name space.

    7.  Every such registry and registrar should reject such
    registration attempts.  

Something along those lines for each requested label.  Also, see below
about particular issues I have.

_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.

Particular items in the draft
=============================

Abstract: "designed to help harden name resolution security,
   provide censorship resistance, and protect the users' privacy on the
   Internet."  

I think that's just polemical.  The purpose of registering these names
is, as I understand it, that they're already in use in deployed
systems, so you need to register them for interoperability purposes.
Right?  I suggest saying that instead.  If you really need a
motivation for the uses, then something like, "designed to help users
in non-DNS contexts where DNS-style names are useful for the
applications described in this memo."  You can get into the motivation
for the applications in the text if you want, but not in the abstract,
please.

Terminology:    
   The acronym "pTLD" is used as a shortcut to mean a pseudo Top-Level
   Domain, i.e., a name or label for a network not present in
   operational DNS, and not registered with IANA for use within the
   scope of operational DNS.

I'm not sure I get this.  If this document is published, what happens
is that the candidate labels become real, genuine labels registered in
the DNS.  It just so happens that they appear in no zones, because
they are in effect allocated and not delegated.  I think of allocated
names as still being 'part of' the DNS: .invalid is still part of the
DNS.  I also think it's confusing to claim that these names aren't
"part of" the DNS when the whole procedure here is in fact for putting
the names into a DNS registry.

   In this document, ".tld" (with quotes) means: any domain or hostname
   within the scope of a given pTLD, while .tld (without quotes), or
   dot-tld, both refer to an adjective form.  For example, a collection
   of ".gnu" peers, but an .onion URL.  The pTLD itself is mentioned
   with dot, and within double quotes, and usually followed by the word
   pTLD.

I find that paragraph confusing, but it appears to be defining a term
that is then used less than rigourously throughout the document.  It'd
be better to define the use once and then make the rest of the draft
consistent with the definition.

The ".gnu" Relative pTLD:

    […] Note that ".gnu"
   names SHOULD follow the naming conventions of DNS.

What does this mean exactly?  Is this the LDH rule?  Case-insensitive
but case-preserving?  Is GNS subject to IDNA?  Or are labels just bags
of octets?  Are they only 63 octets each, with a maximum 255 limit?
"The naming conventions of DNS" have been an endless source of
trouble, and I think this needs to be spelled out in detail, or else
left out completely because it's well-specified somewhere else.

   ".gnu" names are personal, relative, and transitive: each user of the
   GNS controls their own zone that is authoritative for all ".gnu"
   domains; zones can be delegated between authorities, so that any user
   can share names, and chain labels to resolve names out of the
   requesting user's zone of control, including across several zones. 

[and the next paragraph].  I think this probably should be cut.  It's
really a description of how the GNS works, and it is neither detailed
enough to give the reader a sense of how that works (it sounds like
chaos on its own), nor plain enough to require no more explication.

The ".zkey" Compressed Public Key pTLD:

It is very far from obvious, in this draft, why this functionality
requires a whole separate TLD.  It _might_ be because of the reverse
trick, in which case say that.

The ".exit" Client Source Routing pTLD:

This one is especially problematic, because it appears to be a TLD
that results in special handling of the name to control DNS lookups.
This _really_ needs to be unpacked because it will certainly have
implications for the global DNS.  Also, "hostname" in here is a little
confusing.  The example, for instance, is
"gnu.org.f97f3b153fed6604230cd497a3d1e9815b007637.exit".  Once the
.exit TLD is registered, then that becomes a valid hostname (but one
that in principle always returns particular answers).  So, is it ok to
have
"gnu.org.f97f3b153fed6604230cd497a3d1e9815b007637.exit.f97f3b153fed6604230cd497a3d1e9815b007637.exit"?
If not, why not?  If so, what do you do when you run into the total
limit on DNS names?

The ".noconnect" Client Interruption pTLD:

If this label isn't requested, just take this section out.

The ".i2p" Addressbook pTLD:

   Apart from the ".b32.i2p" domain that is reserved for SHA-256 hashes,
   other hostnames within the ".i2p." pTLD are non-hierarchical and can
   be assigned locally: example.i2p and other.example.i2p do not
   necessarily belong to the same authority.

This looks like a recipe for future disaster.  What if you end up with
a different encoding scheme in future?  Don't you need to allow for
that?  Also, I really don't get why this one is a TLD.  It seems
like the sort of name that could be absolutely anywhere in the tree.

The ".bit" Timeline System pTLD:

Why does this need to be a TLD?  This one is to me most fraught,
because (1) namecoin sure looks like an effort that has significant
potential money-generating activity associated and (2) I can't see any
reason this had to be a TLD.

Security Considerations:

   Operation of said TLDs into the global DNS scope could as well
   produce conflicts [SAC45] due to later real use and the possible
   acquisition of intellectual property rights in such names.

   The reservation of several Top-Level Domain names for these purposes
   will minimize such confusion and conflict, and safety risks for
   users.

But if these names are added to the registry (assuming this document
is published) then surely they will _not_ be added to the DNS, because
they're already allocated in the DNS.  No?  Therefore, this isn't a
security consideration of the document, but a consideration in case of
non-document :)

Domain Name Reservation Considerations:

   1.  Users MAY use these names as they would other domain names,
       entering them anywhere that they would otherwise enter a
       conventional DNS domain name, or a dotted decimal IPv4 address,
       or a literal IPv6 address.

Really?  So I can put
ajs@[gnu.org.f97f3b153fed6604230cd497a3d1e9815b007637.exit]?  I bet
not.  It's simply not true that names and numbers can everywhere be
used interchangeably.

   2.  Application Software MAY pass requests to any of the six proposed
       pTLDs for normal DNS resolution if A/AAAA records are desired.
       If available, the local DNS resolver MUST intercept such requests
       within the respective operating system hooks and behave like
       DNS.

That is a _very very_ bad idea.  Either these are special names that
aren't part of the DNS, or they're not.  If they _are_ part of the DNS
because you sometimes want to get DNS data associated with them, then
they're DNS names and there's no excuse for this special registration.
Go apply to ICANN.  If they're not, then you can't have this. 

But I think what this actually means is, "If these are passed to a DNS
resolver, the DNS resolver will follow the usual DNS semantics to
resolve them.  That should result in RCODE=3 (Name Error) because the
TLD labels should never appear in the root of the DNS.  I don't like
the bits in this section that suggest "the resolver" can do different
things, depending.  What is really meant is that a resolver call on a
system might be resolving in more than one name space.  It so happens
that a non-DNS resolver might use these name spaces as triggers to do
something.  In any case, if this owner name reaches the DNS resolver,
then the expected outcome is RCODE=3.  In addition, I wonder whether
this means that these ought to be set up as "default local zones" the
way certain other ones are.  See below.

   4.  […]
       But given that ".bit" users have no special privacy requirements,
       and those names are globally unique, caching DNS servers MAY
       choose to treat them as regular DNS names, and cache the
       responses obtained from the Namecoin block chain as if they were
       resolved from the regular DNS tree.

This is, bluntly, a reason to refuse the .bit registration.  If .bit
wants a TLD, then let them get it.  Otherwise, this is a special name
and shouldn't be in the DNS, period.

   6.  DNS Server Operators MAY choose to resolve ".bit" names using the
       Namecoin block chain, and if they do so SHOULD treat such domains
       like they would regular DNS names.

Same here.  Also,

       DNS Server Operators SHOULD treat requests to the other five
       considered pTLDs as typos, for correct installations MUST NOT
       allow such P2P requests to escape to DNS.

This is ridiculous.  The _whole point_ of these special TLDs is that
you expect to hand these names around as though there's nothing
special about them.  In that case, you absolutely must expect that
these names are going to get to the global DNS (if you think they
won't, then I urge you to consider how much .local traffic makes it to
the root).  Because they don't exist in the root zone, they will be
cached for the negative TTL in the root zone's SOA (currently 1 day,
if memory serves).  So, first, that certainly has effects on DNS
operators.  Second, there's no such thing as "considering a label a
typo" except in the most egregious abuses of the DNS.  What we have is
"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.

Best regards,

Andrew

-- 
Andrew Sullivan
[e-mail]