Re: [DNSOP] On the call for adoption on Special Use Names (Please! Pretty please, with a cherry on top?!)

Paul Wouters <paul@nohats.ca> Wed, 21 September 2016 02:32 UTC

Return-Path: <paul@nohats.ca>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B62412B395 for <dnsop@ietfa.amsl.com>; Tue, 20 Sep 2016 19:32:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.322
X-Spam-Level:
X-Spam-Status: No, score=-3.322 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, PLING_QUERY=0.994, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PDVgX1lRvbfX for <dnsop@ietfa.amsl.com>; Tue, 20 Sep 2016 19:32:30 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1832B12B3CE for <dnsop@ietf.org>; Tue, 20 Sep 2016 19:32:28 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3sf3Yj3hm4z35S; Wed, 21 Sep 2016 04:32:25 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1474425145; bh=jZouZ6q+CqdWatOKcETysj9HnR4wRzh1QQS9Xdb2T40=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=A2H7DtyX6435QA97SjnNWhUetmdlvaD8TVveHkx1inXVVbGjODEl63UTt77eAI7Im WMgucmxo2o3gw8gqvfH/y8XB3suNMy3DvX2VhEavVl9QmkZvZ2wK407lxZk212Xm+l wV8ZrGDTHUqIkrhbFcDPUJhYPrqpk3YEKo4jjohA=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id htXK1Yax0Aka; Wed, 21 Sep 2016 04:32:24 +0200 (CEST)
Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 21 Sep 2016 04:32:23 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id D1C9235A2AE; Tue, 20 Sep 2016 22:32:22 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca D1C9235A2AE
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id B974940D7297; Tue, 20 Sep 2016 22:32:22 -0400 (EDT)
Date: Tue, 20 Sep 2016 22:32:22 -0400 (EDT)
From: Paul Wouters <paul@nohats.ca>
To: Mark Andrews <marka@isc.org>
In-Reply-To: <20160921010115.06D5754B931B@rock.dv.isc.org>
Message-ID: <alpine.LRH.2.20.1609202225100.10296@bofh.nohats.ca>
References: <CAHw9_i+UVH78URWzk+4x=j9BZiKfX3C+UeFU9vz1OfZ3tPeN1Q@mail.gmail.com> <20160920133357.hbvtkrg5uwgzu4wh@nic.fr> <CAHw9_iJ-9mMsu30fyEtJd7y7BPDh3BFjiXOK8dE_UynuF65sPg@mail.gmail.com> <20160921010115.06D5754B931B@rock.dv.isc.org>
User-Agent: Alpine 2.20 (LRH 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/HYRS0WphGTFWaSwBszeP8JdZEP8>
Cc: dnsop <dnsop@ietf.org>
Subject: Re: [DNSOP] On the call for adoption on Special Use Names (Please! Pretty please, with a cherry on top?!)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Sep 2016 02:32:32 -0000

On Wed, 21 Sep 2016, Mark Andrews wrote:

> Below is my overview of the sitution.

I like Mark's summary below. I would add:

11) Some software has taken unused delegations causing dilemmas and/or
technical issues (eg .bit or .gnu)

12) Some hardware has taken unused delegations causing  dilemmas and/or
technical issues (eg .box for Fritzbox, .belkin). [note not all vendors
squated on their own brand, see .box]

And my own personal 13) would be:

 	The IETF would like to avoid making any decisions based on
 	specific names or trademarks, unless these pose a risk to
 	the stability and security of the resolving protocols. For
 	DNS specifically, it refers all naming issues to ICANN.

Paul

> 1) Today domain names are resolved with a number of protocols (e.g.
> DNS, MDNS, TOR, NIS).
>
> 2) Some names are meant to be globally visible (*.onion) and some are
> ment to be only be locally visible (*.local, *.10.in-addr.arpa) and
> for some only the delegated authority knows the desired visibility
> level.
>
> 3) Sometimes the contents of the name signals which protocol should be
> used to resolve the name.  e.g. *.local -> mdns, *.onion -> tor.
>
> 4) Rules are sometimes needed to inform the resolution software about
> which protocol to use.
>
> 5) Rules are sometimes need to handle lookups occuring in the wrong
> protocol or the wrong place. e.g. *.onion in the DNS, AS112 servers
> to 10.in-addr.arpa and locally served local zones, deliberate
> breaking of DNSSEC chains of trust.
>
> 6) Names should only be used to identify stuff when you have been
> delegated them either explicitly or implicitly (e.g. RFC 1918
> implicitly delegates 10.in-addr.arpa to anyone using RFC 1918 space).
>
> 7) The default resolution mechanism is the DNS.  There are standard
> proceedures for delegating names in the DNS.
>
> 8) Sometimes it is necessary to perform non standard delegations that
> don't follow the normal proceedures as the requirements of the
> delegation don't match the normal state of affairs.  The delegation
> of .onion for the use of TOR is a example of such a delegation as
> well as the delegation of .local for MDNS.
>
> 9) Such delegations by their very nature need to be handled on a case-
> by-case basis which needs to be co-ordinated with the delegating
> authority that normally handles that part of the namespace.  They
> are exceptions to the normal rules.
>
> 10) Undelegated use of a name complicates the decision to delegate a
> name either using conventional mechanisms or using exception
> mechanisms.  So to does concurrent requests for a name especially
> a TLD. So to does trade mark issues.
>
>
> In message <CAHw9_iJ-9mMsu30fyEtJd7y7BPDh3BFjiXOK8dE_UynuF65sPg@mail.gmail.com>om>, Warren Kumari writes:
>> On Tue, Sep 20, 2016 at 9:33 AM, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
>>> On Fri, Sep 16, 2016 at 05:53:53PM -0400,
>>>  Warren Kumari <warren@kumari.net> wrote
>>>  a message of 31 lines which said:
>>>
>>>> However, if there is not sufficient review and feedback for the
>>>> chairs to be able to select between them (or some other clear
>>>> outcome), we will be stuck... and then we will continue to talk
>>>> about this topic ad nauseam[0].
>>>
>>> Or we could decide that the problem is not solvable in the current
>>> context and tell that to the IESG.
>>
>> We could -- it is entirely possible that this is not a solvable
>> problem -- however, before we can make that determination, and even
>> more importantly, before we can clearly communicate that to the rest
>> of the IETF / IESG / <etc> we need to agree on what the *problem*
>> actually is.
>>
>> This is what draft-tldr-sutld-ps is trying to do -- clearly document
>> the problems with special use names, not just the problems with
>> RFC6761.
>>
>> Once we've documented the problem we can then discuss *mitigations* (I
>> suspect not solutions), and if there is anything useful we can
>> actually do...
>>
>>
>> W
>>
>>> Some things are simply not
>>> possible. And I'm still not convinced there is a problem to solve
>>> (unless the real issue is "how to prevent the registration of .gnu and
>>> .bit?")
>>>
>>> The rest of this email is about
>>> draft-adpkja-dnsop-special-names-problem-06. Executive summary: no, no
>>> and no.
>>>
>>> Problems
>>> ********
>>>
>>> Despite many remarks on this list and in IETF meetings, the draft
>>> continues to use disparaging terms like (section 1) "squatting".
>>>
>>> Several remarks in the draft are dishonest because they could be
>>> applied as well to many IETF technologies. It really seems the authors
>>> felt the draft was too short and decided to pile in anything they
>>> could find against 6761. For instance, section 3 says:
>>>
>>>> [RFC6761] does not mention if the protocol using the reserved name
>>>> should be published as an RFC document.
>>>
>>> So what? It was never a problem at IETF to rely on protocols which are
>>> not in a RFC. (See for instance the "Specification Required" policy in
>>> RFC 5226.)
>>>
>>> Another instance of the same problem, section 4 says:
>>>
>>>> c.  Reserving a string in [RFC6761] does not guarantee queries will
>>>> not leak in the DNS.
>>>
>>> Requiring this is outrageous: there is no way to prevent
>>> implementations to do stupid things. RFC 1918 does not "guarantee
>>> packets will not leak [in the public Internet]" and nobody is going to
>>> criticize RFC 1918 for that. (Not to mention the DNS leaks of
>>> rfc1918-domains.arpa.)
>>>
>>> Section 5:
>>>
>>>> This leads to concerns about liability risks incurred by adding a
>>>> particular string to the [RFC6761] registry.
>>>
>>> There is no way to guard against any issue that a US lawyer may
>>> raise. Until now, no owner of the Local or Onion trademarks
>>> complained, or threatened to sue.
>>>
>>> Errors
>>> ******
>>>
>>> Section 1 :
>>>
>>>> the GNU Name System (GNS) system is using block chains to build a
>>>> decentralized name system
>>>
>>> GNS does not use any blockchain. (Confusion with Namecoin?)
>>>
>>> Little details
>>> **************
>>>
>>> Abstract :
>>>
>>>> RFC 6761 introduced a framework by which a particular domain name
>>>> could be acknowledged as being special.
>>>
>>> Actually, suffix, not domain name (RFC 6761, section 4).
>>>
>>> Section 1 :
>>>
>>>> An algorithmic solution frequently chosen by application developers
>>>> consists simply in using a special tag padded at the end of a name
>>>
>>> Why calling it "tag", instead of "label" (or "suffix" if there are
>>> several labels)?
>>>
>>
>>
>>
>> --
>> I don't think the execution is relevant when it was obviously a bad
>> idea in the first place.
>> This is like putting rabid weasels in your pants, and later expressing
>> regret at having chosen those particular rabid weasels and that pair
>> of pants.
>>    ---maf
>>
>> _______________________________________________
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>