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

Warren Kumari <warren@kumari.net> Tue, 20 September 2016 13:47 UTC

Return-Path: <warren@kumari.net>
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 537C212B19B for <dnsop@ietfa.amsl.com>; Tue, 20 Sep 2016 06:47:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.606
X-Spam-Level:
X-Spam-Status: No, score=-1.606 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, PLING_QUERY=0.994, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com
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 Uzt-fHSvDutW for <dnsop@ietfa.amsl.com>; Tue, 20 Sep 2016 06:47:07 -0700 (PDT)
Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FFBB12B0B2 for <dnsop@ietf.org>; Tue, 20 Sep 2016 06:47:07 -0700 (PDT)
Received: by mail-qk0-x232.google.com with SMTP id n185so15278811qke.1 for <dnsop@ietf.org>; Tue, 20 Sep 2016 06:47:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JHDfShGhrtT+xCT4iwavx8+Fz4C0o1qPvkp7C83vacY=; b=FOzp3M2mLxYa9lOmSaTIQOc7rPxsvLSAYQutEL4T7SEOtygBG4JHmKynu6R+VGqIPs ZaP/dulOyzwwId2k/ZNasDWBe/EdzHt1hgXjiofacH+yPMzWYedX0kY/2EUF7PzfToiN nDlPbdvoU63NrMwBw+ntn/zglAaByqjQOR4MjwdYeS9gTeQN2Ut/dICLD8EC9XqmVLij 2nZLx8RqJluoQi5wyiMlQp64Zb44D6jd2T7AUArY/85WWGWV7qPW36LpLRIuLN9tVMje +UtzTecQuraECWHSxTohdaHHVmNJ61MX8hIRIbVbcNGKJDW6LitIlCbhx6Y+/7s2L/Pj bkmw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JHDfShGhrtT+xCT4iwavx8+Fz4C0o1qPvkp7C83vacY=; b=lbijUwBFVpNySLKQbwoGQYc3Ir67AQZdA90ay0jVCMDUXTneT5D0ttPEWu42MPmihe 2zswegKcdixNNTLxqnqu2RBHWnp+elEZ/Pyq0Bed7z8F8T4ZvpE+STTZSOcYzo2U/5nh wazU8sqjiH9hXyZsMTxh/O/7kBP5d8UkVK9O4KMveENWK+Qwj6LbYhKqLq6Pk9N2grTT Rlmfr8fJPaoOxdH7+Bs+AFi8kkN0f5iJWEcpTjiOsVSqYgMAJp+GAjKE/6WeXlDlNJF0 KQTBoip7xikwkILXcUS6q/VkImDAp5M/Nw29UnaQi3UJLTVYEYZIspZJSHN+muVseOJ4 Dr/g==
X-Gm-Message-State: AE9vXwPpxwwGKFNlizHmWP9XVv0cvLT3737UnmXIJVYPL4B0y2X07oINPx+OAJQ0vH21SuB+l6Q9TockqMd+3ghO
X-Received: by 10.55.188.195 with SMTP id m186mr37176996qkf.180.1474379226650; Tue, 20 Sep 2016 06:47:06 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.147.196 with HTTP; Tue, 20 Sep 2016 06:46:36 -0700 (PDT)
In-Reply-To: <20160920133357.hbvtkrg5uwgzu4wh@nic.fr>
References: <CAHw9_i+UVH78URWzk+4x=j9BZiKfX3C+UeFU9vz1OfZ3tPeN1Q@mail.gmail.com> <20160920133357.hbvtkrg5uwgzu4wh@nic.fr>
From: Warren Kumari <warren@kumari.net>
Date: Tue, 20 Sep 2016 09:46:36 -0400
Message-ID: <CAHw9_iJ-9mMsu30fyEtJd7y7BPDh3BFjiXOK8dE_UynuF65sPg@mail.gmail.com>
To: Stephane Bortzmeyer <bortzmeyer@nic.fr>
Content-Type: text/plain; charset=UTF-8
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/WFPk7-HkwU4ECsD2qcoWRKf_G9I>
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: Tue, 20 Sep 2016 13:47:12 -0000

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