[DNSOP] ICANN Name collision framework

Rubens Kuhl <rubensk@nic.br> Sat, 19 August 2017 15:47 UTC

Return-Path: <rubensk@nic.br>
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 CDF9613294B for <dnsop@ietfa.amsl.com>; Sat, 19 Aug 2017 08:47:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level:
X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.br
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 YXd9IYTly5gN for <dnsop@ietfa.amsl.com>; Sat, 19 Aug 2017 08:47:51 -0700 (PDT)
Received: from mail.nic.br (mail.nic.br [200.160.4.5]) (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 A9846132941 for <dnsop@ietf.org>; Sat, 19 Aug 2017 08:47:48 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.nic.br (Postfix) with ESMTP id C25AC21565A for <dnsop@ietf.org>; Sat, 19 Aug 2017 12:47:46 -0300 (BRT)
X-Virus-Scanned: Debian amavisd-new at mail.nic.br
Authentication-Results: mail.nic.br (amavisd-new); dkim=pass (1024-bit key) header.d=nic.br
Received: from mail.nic.br ([127.0.0.1]) by localhost (mail.nic.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R7OAfEJQb0Ks for <dnsop@ietf.org>; Sat, 19 Aug 2017 12:47:44 -0300 (BRT)
Received: from [192.168.1.81] (unknown [152.254.218.200]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: rubensk@nic.br) by mail.nic.br (Postfix) with ESMTPSA id AE453215659 for <dnsop@ietf.org>; Sat, 19 Aug 2017 12:47:44 -0300 (BRT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.br; s=dkim; t=1503157664; bh=jiVDbrH9twVcqFZcQRZjLZmvqEWubcQtaMFQj9k7DIw=; h=From:Subject:Date:To:From; b=XnSSR5AIaEaNqBX1BIAWfSsAXQpgg6XhoTkiRVVGN5Mc+8Gg7Ju3PrTTo1gSythCa 1VzjuqCgshDwk7byT83EuGaa1XDLs2suMmZTzyZ8gf8jZj4JqVG4VT7b565W4SnbTl v5Rdry88qD7XdtPwYfLWZQ56Wvn9zlvUj2gMNeWU=
From: Rubens Kuhl <rubensk@nic.br>
X-Pgp-Agent: GPGMail
Content-Type: multipart/signed; boundary="Apple-Mail=_73023A38-B83C-4739-B8F4-641B29C23DA0"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Date: Sat, 19 Aug 2017 12:47:43 -0300
Message-Id: <61AE518D-10D7-42BF-89BE-15FB5DC1EE75@nic.br>
To: dnsop <dnsop@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Mailer: Apple Mail (2.3124)
DMARC-Filter: OpenDMARC Filter v1.3.1 mail.nic.br AE453215659
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/zR-5x4XN7p5DhC52ASsRPrbVOxk>
Subject: [DNSOP] ICANN Name collision framework
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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: Sat, 19 Aug 2017 15:47:54 -0000

(Sorry if you have received more than 1 copy of this e-mail, since this is being sent to technical mailing lists focusing on DNS)

There is ongoing policy development effort within ICANN towards subsequent procedures of new gTLDs releases; during the last round in 2012, one of the last pieces of the program to be defined was the name collision framework, detailed at https://www.icann.org/resources/pages/name-collision-2013-12-06-en <https://www.icann.org/resources/pages/name-collision-2013-12-06-en> .

The current thinking is to keep most of the framework as it was in that round, with minor changes for low risk strings and some more detail for other strings. The base principle is to use research-accessible trusted databases such as DITL and ORDINAL to make decisions.

In chronological order, the process would be like this:

1) Pre-application procedure
ICANN Org would provide a "do not apply" list containing strings like localhost and an "exercise care" list containing strings such as the ones hitting root servers with large number of invalid queries, where it's expected that a non-standard mitigation framework would be required.

2) Application time
Applicants would need to file a mitigation framework for "exercise care" strings but could file one for other strings as well.

3) Evaluation time
Each applied-for unique string would be evaluated and divided into 3 buckets of strings: high-risk strings would have their applications terminated, aggravated risk ones would require non-standard mitigation framework and low-risk strings would use the standard framework. Note that "exercise care" strings might turn out to be low-risk, or strings not listed in any list might turn out to be high or aggravated risk.

4) Controlled interruption
As soon as a decision is made regarding risk assessment, ICANN Org itself would perform 90 days or more of wildcard 127.0.53.53 controlled interruption for all low-risk strings. This would be different from the 2012-round as this was done by registry operators after they got IANA delegation. IANA delegation of those will be actually a redelegation to registry operators.
ICANN Org would have the option to decide answer NXDOMAIN instead of 127.0.53.53 for specific labels that caused disruption, with the understanding that those labels would still require 90 days of controlled interruption to be later used.

5) Aggravated risk strings
Each framework will be evaluated using registry services technical evaluation procedures and carried out by registry operator, with ICANN monitoring its compliance.

Some of the questions still to be answered by the WG include:
- Guidelines, lists and/or procedures for creating "do no apply" and "exercise care" lists
- Guidelines and/or procedures for applied strings risk assessment
- Whether 2-year readiness for collisions with potential harm to human life should still exist since none was detected in the 2012-round, and only 37 collisions were reported to ICANN.
- Whether 2012-round TLDs that already completed their 2-year readiness cycles should still have some kind of operational readiness thru the lifecycle of the TLD.


So, the reasons for outreaching to this technical group include:
- Whether someone has feedback for the current thinking of the process. Nothing is final until they are final.
- Whether someone has feedback on the unanswered questions so progress can be made in those areas.


Thanks!
Rubens Kühl