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

[Patrik Fältström <[e-mail]>]

FWIW, very good summary Andrew. Resonates with what my thinking has been. Thanks!

In short:

This draft do point out a presumed need for other kind of namespaces, most notably ones that:

+ are "local but unique" where each user can have a unique namespace where the name globally is not unique

+ are non-unique globally

+ might be globally unique (some risk exists for collision)

BUT:

The beginning of this summary by Andrew do point out the for me most important thing. That this draft do trigger the need for IETF to understand how to manage the situation where multiple resolution systems do use the same namespace. For URI's IETF have historically used a prefix, a scheme, but for normal use (in web browsers for example) the scheme is no longer required. And not only that, people can today enter random strings in the user interface where the string end up being used for everything from lookups in DNS, via lookups in DNS using search paths, lookups using the DNS protocol in various ways (mdns), or keyword searches to searches in search engines. All of those mechanisms do today implicitly use the http protocol and not even the by IETF invented SRV (or URI or NAPTR) mechanisms are used for discovery of correct protocol and port.

This draft is for me "just the next step" in a natural evolution. But to some degree this is a positive event for me. The authors have obviously understood a namespace collision would be a bad thing for the user experience, and they have contacted the IETF.

To be able to move forward, I think what is needed is (I hope this is a correct understanding of what Andrew have written, and that we because of that do agree):

1. IETF must take the namespace collision issue seriously and discuss how to handle the situation

2. The draft must separate the various different kind of namespaces created, and explain explicitly which one of the strings in this draft is of what kind (and the various namespaces must have stable documentation and explanation of their functionality -- for example by publications of RFCs)

3. The .BIT string seems to be a traditional TLD in the DNS and must to be assigned as such be approved using whatever policies ICANN uses for creation of TLDs

    Patrik

On 31 dec 2013, at 01:04, Andrew Sullivan <[e-mail]> 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.  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]
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop