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

[Christian Grothoff <[e-mail]>]

Dear Andrew,

First of all, thanks for your constructive feedback.  I'll try to
answer some of your questions inline now, and we'll try to address
them in the next revision of the draft as best as we can as well.

On 12/31/2013 01:04 AM, Andrew Sullivan wrote:
> 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.  

What kind of metric do you propose, and how do you propose to acquire it?
Let me give you a few examples:
1) # registered names --- easy for .bit (~100k), kind of possible for
   .i2p (~4000), hard for .onion (no clue), even harder for .gnu.
2) # users of the software --- almost impossible for .bit (no installation
   required), hard to tell for .onion (how to distinguish Tor users of
   .onion vs. "ordinary" Tor users?), hard to tell for ".i2p" (AFAIK
   no build-in mechanism), likely possible with error of factor 2-4 for
   .gnu; also, what's a "user" anyway?  Number of downloads? Number of
   peers running at any time? Number of users over a month?

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.
Saying "once you have a large user base, we'll accept it", means IETF
has decided on a policy where people MUST just take names without checking
with anyone first, and then later "demanding" that they be reserved.
For me, label-squatting implies that someone sits on a label and makes
no use of it; so a better question might be if there should be a process
to "unreserve" names should they fall into disuse.  We've seen this with
IP addresses being returned to the pool, so I can easily imagine having
a mechanism to do this.  Still, given that there are more tLDs than IPv4
addresses, I'm not too concerned that this is an urgent issue that would
need to be addressed immediately.

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

I think that's a fair suggestion, especially as with the addition of
".bit" the answers did get a bit more diverse.

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

Well, they might be configured or modified to return NXDOMAIN, but
I'm not sure if this "configuration" change is intended to be covered
by the question.

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

I was told that i2p2.de recently moved to geti2p.net.  Which other
pages are unstable in your experience? ("Worked for me...").

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

Ok, that's editorial, but a reasonable suggestion.

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

Well, that's going to be a question of what people consider "part of DNS",
but we can probably find a better formulation that avoids this possible
and problematic interpretation.

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

Ok, we'll look into this.

> The ".gnu" Relative pTLD:
> 
>     […] Note that ".gnu"
>    names SHOULD follow the naming conventions of DNS.
> 
> What does this mean exactly? 

Ok, we can make this more precise, I'll try to answer your questions
below.

> Is this the LDH rule?

Yes, in the sense of "SHOULD".

> Case-insensitive
> but case-preserving?  

Yes (on case-insensitive), and SHOULD on 'case-preserving'.

> Is GNS subject to IDNA?

Yes.

> Or are labels just bags
> of octets?  

No.

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

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

I can live with leaving it out. Any objections to that suggestion?

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

Ok.

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

Yes, ".zkey" is indeed used as a way to construct a name when doing
"reverse lookups".

> 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?

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).  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".

> The ".noconnect" Client Interruption pTLD:
> 
> If this label isn't requested, just take this section out.

I can live with this, the question is if anyone feels like this would
be useful for documentation purposes.  But I agree with you that
it can and probably should go. Anyone against it being removed?

> 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?

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

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

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
or names in my local domain (local domain in the sense of
/etc/resolv.conf).

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

Well, I always thought of Namecoin and bitcoin as money-burning
activities, but feel free to invest in Namecoin then ;-).  Still,
I'm not sure I see a provision in RfC 6761 that the activity has
to be non-profit (Apple certainly makes a profit, yet they still
got ".local" for free, right?).

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.

This is again an interesting split in your logic:

You suggest people to reserve pTLDs only once  they've reached
a significant size (namecoin with 100k domains is certainly
the largest of the suggested pTLDs, so you should love it!).
Naturally, if people write RFCs only AFTER they get 100k
users, it will be too late for anyone to listen to your
technical advice.

So if you really want to have these types of debates --- how
people should ideally structure their names and integrate with
DNS --- how can you argue at the same time that they should
first deploy to millions of users before reserving the name?

We have three choices:

1) We can decide that we like to influence people and thus
   should make the barrier to reserve a pTLD deliberately low.

2) We decide that we'll just have to let reality happen and
   at least document the resulting reality of the Internet, or

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

I personally prefer (1), even though our draft largely
represents a case of (2).  Some members here seem to like
to argue for (3) for political reasons (i.e. it is politically
more convenient to ignore reality).


> 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 :)

True. Are you arguing to remove this sentence?

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.

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

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.

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

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"?

Is GNU the DNS stub resolver implemented by libc's NSS a "local DNS
resolver"? The formulation of the draft talks about these kinds of
DNS resolvers --- or simply the "gethostbyname" APIs, whereas I suspect
you talk about the resolves operated by ISPs (such as 8.8.8.8).

Naturally, I might be mistaken about what you dislike, or you might
have simply trouble with our use of terminology and what to suggest
an alternative description?  The point remains that applications
(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.


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

We had some discussions about Namecoin caching (off-list) and caching
and Namecoin seem to be, eh, at odds, at least when it comes to NXDOMAIN.
So this paragraph actually needs to be revisited as the ideal behavior
for NXDOMAIN would be different. This will be updated in draft-2.

>    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,

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).  As ".bit" is not
owned by anyone, your statement of "let them get it" is interesting
--- "them" doesn't exist: AFAIK, there is no business, no (clearly
identifiable) lead developer or designer, just a bunch of people that
run a particular free software implementation and some that contribute
code.  So I suspect any individual buying ".bit" is likely to earn the
scorn of the Namecoin community, and not their trust to "operate" the
TLD, which currently does neither have or need an operator, which is the
key motivation behind the design. (Full disclosure: I'm merely a casual
observer of the Namecoin community, I do not speak for them nor do
I have a ".bit" name or any Namecoin or Bitcoin currency.)

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

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").

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

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.  Right now, a well-configured, 100% RFC-compliant DNS resolver
MUST pass a request for ".onion" to the root.  With this draft, we
want to explicitly ALLOW 100% RFC-compliant DNS resolvers to instead
immediately return NXDOMAIN and thus avoid the security and performance
implications of leaking such queries 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.

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.


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

Happy hacking!

Christian