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

Warren Kumari <warren@kumari.net> Sun, 02 October 2016 00:13 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 F030112B00C for <dnsop@ietfa.amsl.com>; Sat, 1 Oct 2016 17:13:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.605
X-Spam-Level:
X-Spam-Status: No, score=-1.605 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, LOTS_OF_MONEY=0.001, 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 OQPn-IwBi_TV for <dnsop@ietfa.amsl.com>; Sat, 1 Oct 2016 17:13:37 -0700 (PDT)
Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (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 D4D4512B007 for <dnsop@ietf.org>; Sat, 1 Oct 2016 17:13:36 -0700 (PDT)
Received: by mail-qk0-x22f.google.com with SMTP id j129so129719578qkd.1 for <dnsop@ietf.org>; Sat, 01 Oct 2016 17:13:36 -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:content-transfer-encoding; bh=TDCEtibJFxt3PUnEL6vyeOGdpAfpghKnq0UpyZHx8y8=; b=vUjcfey6SDPhJXxALwV8a7O7ljFX2iPTVJDdQ+Yv5ecKLsbFmHMc8hkbr5aMrH4fNG +OWDrKbBXTPKbxGs9eV5Qk2h0YEEbg4tRhkPKyNLQ535huYll3490wvLI71vcTAKW9Ta 2q2BYewqzcFK0Nhq/gmoAq7/o5TLftWpisG7d+wAkG9xI3b7Of4lhGEMmvyL+5SLDnvZ BI9JSouKOaMPlvro897VnvPK04Sr24R0uTIMnD1tl1v4RWRSVXo07P8HxMdk8BuurFYi P5/rkTgbPQFXoACpzueZ65a0/rLpmNqz7MRWA9lLvEuk71G8fuS7nVMdLZgh5m4EG9io k5sQ==
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:content-transfer-encoding; bh=TDCEtibJFxt3PUnEL6vyeOGdpAfpghKnq0UpyZHx8y8=; b=fB+gexZyHZipby/ZdsE1krevKPIO7m2UJnhEteNxCWvt1br3cASd0X9PtUeZbVEcxG 02owN7tLyHqw8F+WAi6XeIdG5KOQwYuhZDph/bNSUV4geJjHTXDGqzPxfvu6tBLEEiW6 SIzHXhRP0k6PzhCqV7JdZatcynvsnSSC6I/JLdEDmyQ0oGLtQQZiYOoc5XNnPVd9OFyn YRmKzr3XBPbrJaiJ1UcGdqmYe6So77tMUNmzcW0b6wybF0r0lG/0TumZ1DfXy44Yjro7 llQiXTVskkRobzk1U08oQEDmitQy0N/R9WWCRh69S3lj4FTh4kMGDoVDo9fIvpeulg/G UVSA==
X-Gm-Message-State: AA6/9RlCwtOct9/lrXgpCU3w5h+SPDhZgf7O8DSQpOgIZgrZDZBhj6FrTPNcU/ByzVmtY/TNSDLor60ZkDTPs4H8
X-Received: by 10.55.151.3 with SMTP id z3mr13295796qkd.321.1475367215849; Sat, 01 Oct 2016 17:13:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.147.196 with HTTP; Sat, 1 Oct 2016 17:13:05 -0700 (PDT)
In-Reply-To: <alpine.LRH.2.20.1610011445540.6522@bofh.nohats.ca>
References: <alpine.OSX.2.11.1609292041280.86752@ary.qy> <CAKr6gn04Jj5ar2OhztH2uc4WpFZBZ=WKZdx-1ufdFMb9NAQupQ@mail.gmail.com> <CAPt1N1=zDBcbaPVi50dFJXVVSrsBuUrb52iBu4T76Y_zYuxFkQ@mail.gmail.com> <CAPt1N1=5kAb20mGLJPmmuQCL6ta9aJn3uEdVv=gVgG9erQoKkw@mail.gmail.com> <CAPt1N1km66hoc7VFPvaHi4Sc0WuQxZFtQUPjLjK_Sj6qAtZ5UQ@mail.gmail.com> <CAPt1N1keNUiDAUuVn97XLb3W6oH7zdZhMeNbg3h-O892+acPVQ@mail.gmail.com> <CAHw9_iKS_BQUV1sJ2vm=CSvHNJ3jH6G8VJKN1kSbc78hauPraw@mail.gmail.com> <alpine.LRH.2.20.1609292250500.13311@bofh.nohats.ca> <CAHw9_iKjfrEHxTA0rkzUa8Y-S_jDqvUxAqH2Yik6a2UiSYViTw@mail.gmail.com> <alpine.LRH.2.20.1610011445540.6522@bofh.nohats.ca>
From: Warren Kumari <warren@kumari.net>
Date: Sat, 01 Oct 2016 20:13:05 -0400
Message-ID: <CAHw9_iJAOWr1RxPfwNgK7hQUuD1eybETAdddySzOLw=8gjsOkw@mail.gmail.com>
To: Paul Wouters <paul@nohats.ca>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/PKP4iuUwnIAGmb2qBuY-R5yivxc>
Cc: dnsop WG <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: Sun, 02 Oct 2016 00:13:39 -0000

On Sat, Oct 1, 2016 at 3:12 PM, Paul Wouters <paul@nohats.ca> wrote:
> On Sat, 1 Oct 2016, Warren Kumari wrote:
>
>>> ICANN already has a blacklist of unsafe domains. IETF can advise them
>>> on that list if needed.
>>
>>
>>
>> No, no it really doesn't -- it has some list of names, which seem to
>> have been fairly arbitrarily chosen. This is not a stable, well
>> published list -- it lurks in the "gTLD Applicant
>> Guidebook", published in January 2012, in Section 2.2.1.2.1 ("It was
>> on display at the bottom of a locked filing cabinet stuck in a disused
>> lavatory with a sign on the door saying beware of the leopard.").
>> This list at that point was: "AFRINIC IANA-SERVERS NRO ALAC ICANN
>> RFC-EDITOR APNIC IESG RIPE ARIN IETF ROOT-SERVERS ASO INTERNIC RSSAC
>> CCNSO INVALID SSAC EXAMPLE* IRTF TEST* GAC ISTF TLD GNSO LACNIC WHOIS
>> GTLD-SERVERS LOCAL WWW IAB LOCALHOST IANA NIC", and "OLYMPIC OLYMPIAD
>> OLYMPIQUE OLYMPIADE OLYMPISCH OLÍMPICO (and Olympic in various scripts
>> which my mailer doesn't want to accept)" and "REDCROSS REDCRESCENT
>> REDCRYSTAL REDLIONANDSUN MAGENDDAVIDADOM REDSTAROFDAVID CROIXROUGE
>> CROIX-ROUGE CROISSANTROUGE CROISSANT-ROUGE CRISTALROUGE CRISTAL-ROUGE
>> (and various Red Cross / Red Crecent and scripts which my mailer
>> shrugged and stared blankly at)".
>>
>> A number of the first list are from the IANA Special Use Names
>> registry -- but many of the others are simply ICANN deciding that
>> their internal groups are special -- for example, GAC, RSSAC, SSAC,
>> CCNSO, ALAC. And then they decided that IETF, IAB, RFC-EDITOR IRTF
>> should also be listed. Seriously, this seems like a good, well run
>> solution?
>
>
> Those are not the "unsafe" domains. Those are all vanity domains, and
> the IETF really does not want to go near those names because it involves
> trademarks and the IETF doesn't have the money for lawyers in that
> arena.
>
>>> I don't think at this point either ICANN or IETF would want to add TLDs
>>> to the unsafe list. If at this point someone is still squatting domain
>>> names, they get what they deserve. And all the known security risky
>>> domains (as a result of decades of use of unqualified domain names)
>>> are already known at ICANN, and they won't assign these.
>>
>>
>> Um. No. See .home, .corp and .mail - many would say that these are
>> known security risky names -- when security issues were raised, these
>> were not placed on a blacklist -- instead these have been "deferred
>> indefinitely. ICANN will collaborate with the technical and security
>> communities to determine the best way to handle these strings in the
>> long term.". I have not seen this happening. Applicants for these TLDs
>> recently sent
>> https://www.icann.org/en/system/files/correspondence/home-registry-inc-et-al-to-icann-board-24aug16-en.pdf.
>> I would encourage all to read this...
>
>
> Right. And these are the only names that have security concerns. And if
> IETF, not ICANN, decides that .mail is a 6761 domain or a 6761bis
> domain, then whoever wants to run .mail will be able to sue the IETF
> instead of ICANN. Which is why ICANN should maintain the list, for
> better or worse. Which is why I came to my one line statement saying
> IETF does not want to have this power to decide this.
>
>>> People creating
>>> new ones are also going against the long standing don't squat advise,
>>> and need no further protection from their own foot bullets.
>>
>>
>> Let's pretend that you had a good reason for needing a name reserved -
>> for example, let's pretend that you are designing some sort of home
>> networking protocol where you'd like to be able to connect thingies
>> together and have name / service discovery just work. It's not mDNS /
>> .local is not appropriate for you. You go through the full IETF
>> process - you hold a BoF, you form a WG, you hold meetings, you design
>> a system. Great. You have IETF consensus. Now what?
>
>
> This is assuming there is a 6761 or 6761bis procedure. What I am saying
> is that the above described scenario is _not_ something the IETF wants
> to be part of. The IETF should say "use a domain you own". Your protocol
> for your new homenet could use smartypants.kumari.net. And it could be
> either delegated by you or you will never delegate if that's required
> for your protocol. If the name is too long, the market can come up with
> a url/domain shortening service.
>
>> Currently you / I / the IETF cannot go to ICANN and say "please
>> reserve us a string" -- there is no "blacklist", there is just some
>> list in some applicant guidebook.
>
>
> Well, "currently" there is disagreement about if the IETF can reserve
> a string, due to the existence of 6761, the claim that this path has
> been frozen, and the claim that it cannot be frozen until it is formally
> closed with a new rfc document. My proposed one liner would permanently
> close this.
>
>> There is no open process at the
>> moment -- the last round took many many painful years, and there was
>> no method to "reserve" a name (in fact, this was explicitly
>> prohibited). The "list" was not created with the consultation of the
>> community - in fact many names on that list a: didn't know that they
>> were, and b: didn't want to be. Also, the process is currently closed,
>> and even if it were open, last time it cost >$185,000 to apply...
>
>
> I don't see how this relates to the discussion. I think the goals are that
> the IETF should not get involved in Naming Schemes and Trademark Wars.
> Because we don't have the budget for it. That's why ICANN was created.
>
>> You've been to a number of ICANN meetings - do you really trust this
>> process to provide a good outcome for the technical community?
>
>
> I think it is adequate and the best IETF can do based on its monetary
> resources.
>
> I do not think the IETF should create "Special Names" that conflict
> with the naming process which has been delegated to ICANN.
>
> Yes, there is a change ICANN decides to delegate names that the IETF
> believes endangers the security and stability of the DNS, such as the
> .mail domain. But if we create a process within the IETF that hard-fails
> those domains out of the hands of ICANN, it just means those lawsuits
> will come to the IETF. And the IETF didn't get 1500 * $185k to defend
> itself.
>
>> Sure, many people didn't like the .ONION discussion / outcome -- but
>> what would your advice have been to the TOR community if we'd already
>> decided to abdicate our position? "Dear TOR folk. Go talk to ICANN..
>> Yeah, I know that that won't actually help you; you don't fit in their
>> model, and the process isn't open now anyway. Guess you shouldn't have
>> squatted on that name, huh"?
>
>
> The IETF giving them .onion in itself has been a very risky decision. It
> was based on no Big Corporation having an interest in the string. With
> .gnu people did not feel as sure about that. I think that's part of the
> reason .gnu was not also going to make it like .onion. These decisions
> are quicksand.
>
>> Anyway, this is FAR into the solution space, and I was really hoping
>> to avoid getting drawn into that..
>
>
> Well, that is because we don't agree about the problem whatsoever. I
> think the only problem we have now with naming is that the IETF has
> some form of control over names via 6761, and leaves us vulnerable to
> lawsuits and therefor I want the IETF to lose that power. That's
> completely unrelated to the entities that are lined up for asking the
> IETF for a decision on a Special Name.
>
>> I know I'm sounding frustrated / grumpy -=- this whole processes /
>> discussion has been taking up way way too much of our time, hopefully
>> we can *soon* make a decision, ship a document and then get onto more
>> *technical* discussions like "Um, which name is the QNAME?!" :-)
>
>
> I have been shouted to sit down when I brought up this is taking too
> much time out of dnsop, so believe me I know how you feel :)

Yup. Hopefully a decision on what to do is made, and made soon -- this
whole process has been painful for / harmful to the working group.
It is largely a political morass, and people are becoming
(understandably!) frustrated, worn out, apathetic, polarized or
entrenched (choose 5!)


W


>
>>>
>>> So that brings the problem statement to:
>>>
>>>         IETF had the power to allocate or ban domain names based on the
>>>         Special Names RFC-6761. IETF no longer wants that power.
>>
>>
>> That's not a problem statement. That's a "we found this annoying and
>> want someone else to do it" -- that may be true, but that's a
>> /solution/, not a /problem statement/.
>
>
> So change the second sentence to "This is a dangerous liability for the
> IETF".
>
> Paul



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